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>
kevans on May 30 2019, 4:15 AM.Authored by
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.
We are also interested in this interface.
Kyle, is there any public repository where we can see the ported version of switch (4)?
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?
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.
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.
Does that mean, the code is incomplete on purpose?
Given, my efforts of my (stalling) reviews, that's not a very peasant reasoning.
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'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 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.