In D17987#389775, @v.maffione_gmail.com wrote:

The truth is that netmap not setting the IFCAP_NETMAP flag in ifp->if_capabilities after r307394 is a mistake that we did not notice so far.
It got introduced by refactoring, 3 years ago (see https://github.com/luigirizzo/netmap/commit/5d0796f93a1107eb14422c7b8ea416f7fd750a2e).
Sorry for that, it was unintended.
I just happened to notice that and fix it.

The cxgbe part of this diff reverts r309725. The commit message for r309725 indicates the changes were made to catch up with r307394, which was the a netmap update. Can you confirm that various releases of netmap have had different behavior regarding if_capabilities? If netmap has finally settled on handling the caps this way then I have no objection to one last catch-up in the driver.

lazy_tx_credit_flush in the driver is supposed to avoid the situation you described. Try setting it to 1 if it isn't already and see if that helps.

+Vincenzo for the netmap_kern.h part.

How about using __aligned(CACHE_LINE_SIZE) like the rest of the driver and let the compiler figure out the padding?

Can you provide exact steps to reproduce the problem that you described? I get an EAGAIN (as expected) and not a panic if I try to enable netmap when the link is down.

In D17843#381477, @ae wrote:

Hi, I have a report, that cxgbe driver doesn't take into account packets, that are received from mirrored port. So, when you run netstat -hw 1 -I cxl0 you will see no packets, but tcpdump will show them. It seems a bit confusing. I didn't checked this, so I might be wrong.

What version of FreeBSD is this? I think this is already fixed in 12.0.

I'll check this into FreeBSD later today. Please send the patch upstream too.

Where is the real upstream for rping? Maybe this fix should go there first?

This looks quite hacky to me. A better fix might be to properly purge
the fields whose meaning depends on the "direction" (tx or rx) of the
mbuf when its direction changes. I think we do something similar for
layer-specific bits that are purged every time an mbuf crosses a layer.

Initializing sc->nqsets here means it may not have a good value until a
port (any port) of the adapter is brought up administratively. This may
work for netdump. If not then setup sc->nqsets in t3_sge_prep instead,
which runs very early.

I tried the latest diff and ran into an assertion on VLAN creation:

I decided to grab the PCP from the ifvlan (like VLAN_TAG does). I believe ifconfig ... vlanpcp <foo> updates this field.
ifconfig ... pcp <foo> updates the if_pcp field but I don't see any code that attempts to keep the ifvlan's pcp
and the ifnet's pcp in sync when the ifnet is a vlan ifnet.

This is modeled after VLAN_TAG (which is mislabeled and just returns the
vid instead of the entire tag). I'm ok with changing the behavior of
VLAN_TAG to return the full tag including pcp but I went with a separate
VLAN_PCP to avoid surprising existing users of VLAN_TAG.