Page MenuHomeFreeBSD

Port if_vether from OpenBSD
Needs ReviewPublic

Authored by kevans on May 30 2019, 4:15 AM.

Details

Reviewers
rgrimes
Group Reviewers
network
manpages
Summary

if_vether is a virtual Ethernet interface. The tentative plan is to use it for vlan+bridge regression testing.

Ported by: Henning Matyschok <henning.matyschok outlook com>

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 24600

Event Timeline

kevans created this revision.May 30 2019, 4:15 AM
koobs added a subscriber: koobs.May 30 2019, 11:16 AM
kevans edited the summary of this revision. (Show Details)May 30 2019, 1:27 PM

Could you please supply use case? Why do we need another virtual ethernet interface? We already have many kinds of them.

kevans added a subscriber: kp.Dec 4 2019, 2:11 PM

Could you please supply use case? Why do we need another virtual ethernet interface? We already have many kinds of them.

As it says in the review body -- bridge(4) regression testing was/is the first candidate for use. My initial plan for testing was to spawn up a bridge and stick N of these in it in different configurations. This review has been sitting long enough now that I don't recall if I decided that wasn't feasible in the meantime (or if @kp had already had other plans), but if it is it'd be more convenient than epair -- with this, you have the absolute bare minimum needed to get a packet from bridge to userspace in 329 total lines of file without also pair management in between.

The person that originally ported this also has some use-case, but I don't recall if I've been told what it is or not. This currently lives in ports as net/vether-kmod.

kevans added a comment.Dec 4 2019, 2:12 PM

Oh, and I also ported switch(4) that's almost functional -- you throw this in a switch(4) to get local traffic out of it.

We are also interested in this interface.
It looks good for use with vale (4) to connect a virtual network to the host stack: bhyve VM's - vale (4) - if_vether (4) - Host. I tested this and it works well. But now we use if_epair (4) for this configuration, because I didn't know about the existence of the port.

Kyle, is there any public repository where we can see the ported version of switch (4)?

kevans added a comment.Dec 4 2019, 7:22 PM

We are also interested in this interface.
It looks good for use with vale (4) to connect a virtual network to the host stack: bhyve VM's - vale (4) - if_vether (4) - Host. I tested this and it works well. But now we use if_epair (4) for this configuration, because I didn't know about the existence of the port.

Kyle, is there any public repository where we can see the ported version of switch (4)?

There is, but I'm quite embarrassed by the current state of the commit history. I'll work on cleaning it up tonight and hopefully fix the remaining issues.

kp added a comment.Dec 4 2019, 7:35 PM

Could you please supply use case? Why do we need another virtual ethernet interface? We already have many kinds of them.

As it says in the review body -- bridge(4) regression testing was/is the first candidate for use. My initial plan for testing was to spawn up a bridge and stick N of these in it in different configurations. This review has been sitting long enough now that I don't recall if I decided that wasn't feasible in the meantime (or if @kp had already had other plans), but if it is it'd be more convenient than epair -- with this, you have the absolute bare minimum needed to get a packet from bridge to userspace in 329 total lines of file without also pair management in between.

I have plans (and minor in-progress work) to do bridge tests with if_epair. I've not really found if_epair to be burdensome to write test withs (aside from its tendency to expose locking issues in the network stack).

Speaking of locking, don't we need any in if_vether?

It look like duplicate work compared to ng_eiface and ng_bridge.
What are the benefits of this interface over the ng ones?

kevans added a comment.Dec 4 2019, 8:42 PM
In D20468#496095, @kp wrote:

Could you please supply use case? Why do we need another virtual ethernet interface? We already have many kinds of them.

As it says in the review body -- bridge(4) regression testing was/is the first candidate for use. My initial plan for testing was to spawn up a bridge and stick N of these in it in different configurations. This review has been sitting long enough now that I don't recall if I decided that wasn't feasible in the meantime (or if @kp had already had other plans), but if it is it'd be more convenient than epair -- with this, you have the absolute bare minimum needed to get a packet from bridge to userspace in 329 total lines of file without also pair management in between.

I have plans (and minor in-progress work) to do bridge tests with if_epair. I've not really found if_epair to be burdensome to write test withs (aside from its tendency to expose locking issues in the network stack).

Yeah, so the main benefits I saw at the time were that you could sidestep the complexity of epair and use half the interfaces for actual testing. OTOH, if you already have infrastructure that deals in terms of epair, there's not much advantage to using anything else.

Speaking of locking, don't we need any in if_vether?

Likely, but I had failed to get anyone else to look at this and promptly lost interest because this isn't an area I work in often.

It look like duplicate work compared to ng_eiface and ng_bridge.
What are the benefits of this interface over the ng ones?

The primary benefit is that it doesn't require netgraph on systems that aren't already using netgraph.

Speaking of locking, don't we need any in if_vether?

Likely, but I had failed to get anyone else to look at this and promptly lost interest because this isn't an area I work in often.

Does that mean, the code is incomplete on purpose?
If yes, I'd veto it.

It look like duplicate work compared to ng_eiface and ng_bridge.
What are the benefits of this interface over the ng ones?

The primary benefit is that it doesn't require netgraph on systems that aren't already using netgraph.

Given, my efforts of my (stalling) reviews, that's not a very peasant reasoning.
You are going to set up a test-bed and refuse to use the existing opportunities?

kevans added a comment.EditedDec 4 2019, 9:09 PM

Speaking of locking, don't we need any in if_vether?

Likely, but I had failed to get anyone else to look at this and promptly lost interest because this isn't an area I work in often.

Does that mean, the code is incomplete on purpose?
If yes, I'd veto it.

I don't think this is a fair extrapolation of what I stated. =\ It's not intentionally incomplete -- it's that I lack the domain knowledge to assess where the potential locking concerns are w.r.t. how the rest of the ethernet infrastructure (edit: operates). I put it up for review based on what's available in the port to get some insight from those that do.

It look like duplicate work compared to ng_eiface and ng_bridge.
What are the benefits of this interface over the ng ones?

The primary benefit is that it doesn't require netgraph on systems that aren't already using netgraph.

Given, my efforts of my (stalling) reviews, that's not a very peasant reasoning.
You are going to set up a test-bed and refuse to use the existing opportunities?

It's more that I'm going to set up a test-bed, and this is both lightweight enough to be added to GENERIC (thus generically useful for whatever test setup it runs under that may or may not be able to load kmods) and it has utility for other people beyond what I'm personally doing with it.

I would encourage continued work on this and the switch code too.

I would encourage continued work on this and the switch code too.

I will gladly do so with some pointers to what it's missing. =) I've been bitten by overlooking things here (in general) that are likely completely obvious to people that frequently work with ifnet stuff, e.g. if_free is async and there's no guarantee that ifioctl handlers have all completed or even started by the time it returns.

kevans added a comment.EditedDec 5 2019, 2:07 PM

I would encourage continued work on this and the switch code too.

I will gladly do so with some pointers to what it's missing. =) I've been bitten by overlooking things here (in general) that are likely completely obvious to people that frequently work with ifnet stuff, e.g. if_free is async and there's no guarantee that ifioctl handlers have all completed or even started by the time it returns.

Actually, this is a more general problem that we need to fix. ifnet used to not be async, and now it is but we didn't grow a callback for drivers to do post-free cleanup (e.g. softc members), so instead we get ad-hoc dirty hacks like I added in tuntap (see: tun_ioctl_sx) to make up for it.

Post-mortem edit: D22691 has been opened to address this. Looking back at stable/11, if_free was still synchronous but the interface still isn't guaranteed to actually be freed and out-of-use until the refcount drops, so cleaning up of softc context should be deferred. It's not a problem introduced by the now-async-if_free.

Hi, Checked the vether module for a month under high load ( 13-CURRENT ). I can say that at present this is the only stable way to interact with traffic inside the VALE switch from the host system. if_epair is extremely unstable. It would be very helpful to see the movement of this work.

emaste added a subscriber: emaste.May 13 2020, 12:04 AM