It would be good to note also about the error when you can not modify partition table until it will be recovered.
This is frequent problem when GPT is marked as CORRUPT.

I'm not sure about GPT volume labels. What will be if you do something like this?

MD=`mdconfig -s 100m`
gpart create -s GPT $MD
gpart add -t freebsd-ufs $MD
for i in `seq 0 100`; do
    gpart modify -i 0 -l LABEL$i $MD
done

In D12040#250190, @cramerj_intel.com wrote:

Perhaps a rename of the new files to reflect the technology/enhancement you are proposing? Most people won't associate Yandex with VLANs. Regardless, to really benefit FreeBSD in general, you should probably include patches to other drivers as well, since VLANs are not specific to Intel devices.

In D12040#249735, @oleg wrote:

Why not? I'm going to use ck library in ipfw, and put related code here to reduce diffs.

perhaps you can avoid ck/atomic: protect yndx_vlan_set() call with IXGBE_RX_LOCK()

In D12040#249728, @oleg wrote:

1. Why is ck library used and not atomic(9) ?

In D11370#249578, @mjoras wrote:

Great. For my own curiosity, are your direct vlan handling patches posted anywhere?

I also did the same test with vlans created on top of lagg with 2x25G mellanox adapters.
I didn't see measurable performance drop there. It is able to forward 14Mpps with our RX direct vlan handling patch.

I have tested your patch in our test environment against forwarding performance.
[packet generator] -> [ switch ] -> [ix.10 -> ix.100]

I proposed this patch for the discussed problem:
https://lists.freebsd.org/pipermail/freebsd-net/2016-December/046650.html

What it we replace IPSEC with IPSEC_SUPPORT?
Then the profit will have those

• who doesn't use IPsec will not rebuild the kernel to avoid overhead
• who want to use IPsec, they can do kldload ipsec
• who want to use TCP-MD5, they can do kldload tcpmd5

From a quick look, the iflib code does not bind irq to CPU cores. The old em/igb drivers did that and I guess, if you add bus_bind_intr() again, this will increase the performance.

The forwarding test is not rely on the described feature. It uses small packets that are each fits into one mbuf and there is no need to collapse or defrag them.

Please, describe in commit message your calculations.

In D11370#236225, @mav wrote:

In D11370#236121, @matt.joras_gmail.com wrote:

The reasoning for keeping the counter increment under the lock is to protect against the possibility of the vlan ifnet being freed while we are touching the counter, since the vlan ifnet can't be freed while we still have the read lock.

It looks odd to me that network stack does not protect against this. What if interface decide to go away earlier, just after entering vlan_transmit? I have subtle feeling that this may only hide the problem.

In D10533#218288, @rgrimes wrote:

Quick glance for 2 minutes says we should probably have a man page change with this?

Make refragmentation to be working.