Thu, Dec 6
Thu, Nov 29
Tue, Nov 27
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.
Mon, Nov 26
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.
Mon, Nov 19
Nov 9 2018
Nov 6 2018
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?
Nov 5 2018
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.
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.
Nov 2 2018
Oct 31 2018
Oct 30 2018
Oct 29 2018
I'll check this into FreeBSD later today. Please send the patch upstream too.
Oct 27 2018
Oct 25 2018
Where is the real upstream for rping? Maybe this fix should go there first?
Oct 23 2018
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.
Oct 22 2018
Oct 17 2018
Oct 16 2018
Oct 13 2018
Sep 26 2018
Sep 25 2018
Sep 22 2018
Sep 21 2018
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.
Sep 18 2018
Sep 13 2018
Aug 29 2018
Aug 28 2018
Aug 24 2018
I tried the latest diff and ran into an assertion on VLAN creation:
Aug 23 2018
Aug 21 2018
Aug 20 2018
Aug 18 2018
Aug 17 2018
Aug 16 2018
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.