if_vether is a virtual Ethernet interface. The tentative plan is to use it for vlan+bridge regression testing.
Ported by: Henning Andersen Matyschok, 120179M11214, USAF
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 24600
Event Timeline
Comment Actions
Could you please supply use case? Why do we need another virtual ethernet interface? We already have many kinds of them.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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)?
Comment Actions
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.
Comment Actions
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?
Comment Actions
It look like duplicate work compared to ng_eiface and ng_bridge.
What are the benefits of this interface over the ng ones?
Comment Actions
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.
The primary benefit is that it doesn't require netgraph on systems that aren't already using netgraph.
Comment Actions
Does that mean, the code is incomplete on purpose?
If yes, I'd veto it.
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?
Comment Actions
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.
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
I have changed som details from present implementation, e. g. replaced subr. for ransomized lla (ether_addr{}, ifaddr{}) and softintr (netisr(9) for broadcasting frames via running instance of if_bridge(4).
Comment Actions
So, I've submitted recent changes, upstream - see "P520" entiteled with "if_vether(4), further developement". Well, I've replaced ether_gen_addr(9) by vether_ifaddr_init(9) for init. randomized lla. by utilizing arc4rand(9). Further, netisr(4) component / facility still used for softint. maps-to bridge_output(9), still operates as Service Access Point (SAP) for broadcasting frames by running instance-of if_bridge(4)-component. Btw. namespace for primitives over ioctl(2)-requests.
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
| share/man/man4/vether.4 | ||
|---|---|---|
| 17–19 | What are the post-git-migration rules for new imported manual pages? Does $FreeBSD$ stay? Do "$Mdocdate:" and "$" get stripped out? (Question, not change request. I don't know and would like someone who does to look at it.) | |
| share/man/man4/vether.4 | ||
|---|---|---|
| 17–19 |
$FreeBSD$ is a svn keyword, and since the move to git invalidates them, current practice is to remove it whenever it's found in files that're being edited for other reasons. .Dd will also need to be bumped when this is committed, but that can be left as an exercise to whoever gets the pleasure of that. :) | |
| share/man/man4/vether.4 | ||
|---|---|---|
| 17–19 | The current practice isn't to remove $FreeBSD$. Leave them be. They will be dealt with all at once in the future. | |
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
Comment Actions
Is something going wrong with some tooling? Because it looks like your diffs are being applied as comments, not to the revision itself?
This comment was removed by henning.matyschok_outlook.com.
This comment was removed by henning.matyschok_outlook.com.
Comment Actions
How are you updating this review when you change file content? Your changes wind up in comments instead of updated diffs.
This comment was removed by henning.matyschok_outlook.com.
Comment Actions
I haven't tested this yet but (hey @kp!) might this solve or probably could easily made to solve (using link[0-2]) an issue people have with a physical interface + Bridge + VLANs setup by being able to attach this to the bridge for the untagged default VLAN?
Would something like this work if we'd say "if link0 is set ignore all tagged packets")?
phyIF --- brdigeN --- vlan10 (vid=10)
--- vlan20 (vid=20)
--- vether0 (untagged only; ifconfig vether0 link0)
--- epairNa ----- another vnet --- epariNb (tags + untagged) --- +++I am still not sure why this needs special knowledge about bridge(4) rather than having ether_output() do what it knows about but I am sure this has its purpose...
| share/man/man4/vether.4 | ||
|---|---|---|
| 38 | What address is meant here? Routing is a L3 function but I have a feeling a L2 address is meant? | |
| sys/net/if_vether.c | ||
| 167 | Vertical spaces here and throughout the file should be cut out... | |
| 303 | Extra vertical space; and if it's Three cases, call them 1/2/3 not a/b/c :-) | |