Page MenuHomeFreeBSD

e1000: Fix up HW vlan ops

Authored by kbowling on Apr 27 2021, 2:15 AM.


  1. Call down to the hw support routine on vlan register and unregister events
  2. Don't muck with the vfta if we aren't doing HW vlan filtering
  3. On the I350 there is a specification update (2.4.20) in which the suggested workaround is to write to the vfta 10 times (if at first you don't succeed, try, try again). Our shared code has the goods, so use it.
  4. Increase a VF's frame receive size in the case of vlans

Inspired by PR 230996 but unspecific and not sure what will happen
Tested by: Özkan KIRIK <>
MFC: 2 weeks

Test Plan

See if folks in PR 230996 have any luck

Diff Detail

R10 FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kbowling created this revision.
  • Don't flap the link on vlan changes
  • Disable interrupts when programming a lem-class filter

When an interface is first brought up, I believe we'll have adapter->num_vlans == 0 and thus won't set CTRL.VME. This means that the NIC will discard VLAN-tagged packets - is that the expected behaviour when vlan(4) isn't in use? I guess it matches the behaviour we had before if VLAN_HWTAGGING is set, but I'm not sure what's correct here.


This check is unreachable, we will return above if this is a VF.


Other platforms seem to set CTRL.VME unconditionally as long as HW Tagging capability is active (which we handle correctly lower in this patch). I guess we should match that.

I think VME is "safe" to have off without VLANs, unexpected 802.1Q packets should come up into the software stack as long as they pass any other filters whether VME is on or off ( in the I210 datasheet).

I have a WIP to manage the VFE when in promiscuous mode so I'm leaning toward removing this condition now that you bring it up. I /think/ VFE is the one we need to be more careful with.

Thoughts on this?


I copied this dead code just like it is over from the out of tree igb-2.5.18. I think the early return above was done because the rest of this filter management isn't ready for VFs. I was mulling over leaving this as a place holder if to try and implement more of the igb VF driver, or if that is just too much work with too little reward it can be nixed. What should we do with WIP/dead code versus the OOT driver?


@markj I've done a bit more research and there is evidence of people trying to use the igb vf driver vf . Can I leave this in as a placeholder for some follow on work after I've made progress on some of the other basic functionality bugs people are having?

Enable the VME bit if IFCAP_VLAN_HWTAGGING. Some better logic around the VFE bit, disable it when promiscuous. Add some helper functions for filter stuff.

Some improvements to SRRCTL related settings pointed out by Kaho Toshikazu <> in PR 230996

bugfix for em_if_vlan_filter_capable

Spotted one more error after the last

This seems ok on I210 but I am having a link stability issue on I219 after I add a vlan. I will need to check out the txrx code.


Indentation's off here.


Ok, I would suggest adding a /* XXX incomplete VF support */ comment or so.


Why this change? The out-of-tree driver appears to re-initialize the driver when registering or unregistering VLANs.


We don't want to flap the link when doing this, it impacts the user experience. So far it looks like it was just a heavy hitting way to get the filter to reprogram but I think I've addressed it, I'll need to watch closely for unexpected change.


Is this right for large MTUs? isc_max_frame_size can be larger than the receive buffers allocated by iflib. I believe iflib will allocate at most 4KB for a contiguous buffer, based on iflib_fl_setup().

I see that we supposedly handle adapter->rx_mbuf_sz > 4096 here but I think it's effectively dead code, see iflib_get_mbuf_size_for().


Ahh I do see the issues, I'll fix this.

Remove unrelated changes, rebase on main

This revision is now accepted and ready to land.Wed, Sep 15, 8:03 PM