nics using if_qlnxe can't be used as laggdev in a lagg interface, unless they are put to promiscuous mode. Tried configuring -vlanwhtag -vlanhwfilter on the interfaces as well, but to no effect (seems to be ignored by the driver completely) without promiscuous mode the interfaces look as followed: >ql0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000 > options=507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO> > ether 94:f1:28:b3:07:96 > media: Ethernet autoselect (10Gbase-SR <full-duplex>) > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > drivername: ql0 > plugged: SFP/SFP+/SFP28 10G Base-SR (LC) > vendor: OEM PN: SFP-10G85-SR SN: CB220919746 DATE: 2022-09-20 > module temperature: 36.42 C voltage: 3.26 Volts > lane 1: RX power: 0.55 mW (-2.61 dBm) TX bias: 6.40 mA >ql1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000 > options=507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO> > ether 94:f1:28:b3:07:96 > hwaddr 94:f1:28:b3:07:97 > media: Ethernet autoselect (10Gbase-SR <full-duplex>) > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > drivername: ql1 > plugged: SFP/SFP+/SFP28 10G Base-SR (LC) > vendor: OEM PN: SFP-10G85-SR SN: CB220919740 DATE: 2022-09-20 > module temperature: 35.63 C voltage: 3.26 Volts > lane 1: RX power: 0.59 mW (-2.29 dBm) TX bias: 6.15 mA >lagg0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000 > options=507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO> > ether 94:f1:28:b3:07:96 > hwaddr 00:00:00:00:00:00 > inet 172.16.200.30 netmask 0xffffff00 broadcast 172.16.200.255 > laggproto lacp lagghash l2,l3,l4 > lagg options: > flags=94<USE_NUMA,LACP_STRICT,LACP_FAST_TIMO> > flowid_shift: 16 > lagg statistics: > active ports: 0 > flapping: 0 > lag id: [(0000,00-00-00-00-00-00,0000,0000,0000), > (0000,00-00-00-00-00-00,0000,0000,0000)] > laggport: ql0 flags=0<> state=47<ACTIVITY,TIMEOUT,AGGREGATION,DEFAULTED> > [(8000,94-F1-28-B3-07-96,0112,8000,0005), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql1 flags=0<> state=47<ACTIVITY,TIMEOUT,AGGREGATION,DEFAULTED> > [(8000,94-F1-28-B3-07-96,0112,8000,0006), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > groups: lagg > media: Ethernet autoselect > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > drivername: lagg0 with promiscuous mode set on the qlX interfaces (`ifconfig qlX promisc`) lagg works just fine: > ql0: flags=1028943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC,LOWER_UP> metric 0 mtu 9000 > options=507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO> > ether 94:f1:28:b3:07:96 > media: Ethernet autoselect (10Gbase-SR <full-duplex>) > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > drivername: ql0 > plugged: SFP/SFP+/SFP28 10G Base-SR (LC) > vendor: OEM PN: SFP-10G85-SR SN: CB220919746 DATE: 2022-09-20 > module temperature: 36.42 C voltage: 3.26 Volts > lane 1: RX power: 0.55 mW (-2.61 dBm) TX bias: 6.40 mA > ql1: flags=1028943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC,LOWER_UP> metric 0 mtu 9000 > options=507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO> > ether 94:f1:28:b3:07:96 > hwaddr 94:f1:28:b3:07:97 > media: Ethernet autoselect (10Gbase-SR <full-duplex>) > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > drivername: ql1 > plugged: SFP/SFP+/SFP28 10G Base-SR (LC) > vendor: OEM PN: SFP-10G85-SR SN: CB220919740 DATE: 2022-09-20 > module temperature: 35.63 C voltage: 3.26 Volts > lane 1: RX power: 0.59 mW (-2.29 dBm) TX bias: 6.15 mA >lagg0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000 > options=507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO> > ether 94:f1:28:b3:07:96 > hwaddr 00:00:00:00:00:00 > inet 172.16.200.30 netmask 0xffffff00 broadcast 172.16.200.255 > laggproto lacp lagghash l2,l3,l4 > lagg options: > flags=94<USE_NUMA,LACP_STRICT,LACP_FAST_TIMO> > flowid_shift: 16 > lagg statistics: > active ports: 2 > flapping: 0 > lag id: [(8000,94-F1-28-B3-07-96,0112,0000,0000), > (8000,A4-4C-11-B8-6F-01,001D,0000,0000)] > laggport: ql0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING> > [(8000,94-F1-28-B3-07-96,0112,8000,0005), > (8000,A4-4C-11-B8-6F-01,001D,8000,012A)] > laggport: ql1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING> > [(8000,94-F1-28-B3-07-96,0112,8000,0006), > (8000,A4-4C-11-B8-6F-01,001D,8000,0129)] > groups: lagg > media: Ethernet autoselect > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > drivername: lagg0
The same issue is present in 15.0-RC3.
(In reply to peter.sopko+freebsd.org from comment #0) > nics using if_qlnxe can't be used as laggdev in a lagg interface, unless they are > put to promiscuous mode. It appears the interface is filtering out the LACP packets ( slow proto, aka ether proto 0x8809 ), so the promiscuous mode comes a rescue. Can you do traffic sniff on one of the lagg member say ql0 ? Please do not enable the promiscuous mode, you can do that with ``` # tcpdump --no-promiscuous-mode -envi ql0 ``` and share the captured traffic ?
I tried capturing traffic on the ql0 interface when it is not set to promisc mode using the command you suggested, but there appears to be absolutely no traffic captured at all... I took a look at the switch where the port is connected and the interface is in an initializing state (but as soon as I put it to promisc mode it is up and running perfectly).... relevant switch configuration for reference: > interface port-channel30 > speed 10000 > description mysql01 > > interface Ethernet1/41 > lacp rate fast > description mysql01 - 1 > channel-group 30 mode active > > interface Ethernet1/42 > lacp rate fast > description mysql-01 -2 > channel-group 30 mode active show interface output (~ 1 minute after I disabled promisc mode, enabled tcpdump and cleared counters): > Ethernet1/42 is down (initializing) > Dedicated Interface > Belongs to Po30 > Hardware: 100/1000/10000 Ethernet, address: a44c.11b8.6ef1 (bia a44c.11b8.6ef1) > Description: mysql-01 -2 > MTU 9216 bytes, BW 10000000 Kbit, DLY 10 usec > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation ARPA > Port mode is access > auto-duplex, 10 Gb/s, media type is 10G > Beacon is turned off > Input flow-control is off, output flow-control is off > Rate mode is dedicated > Switchport monitor is off > EtherType is 0x8100 > Last link flapped 00:00:02 > Last clearing of "show interface" counters 00:01:09 > 2 interface resets > Load-Interval #1: 30 seconds > 30 seconds input rate 80 bits/sec, 0 packets/sec > 30 seconds output rate 488 bits/sec, 0 packets/sec > Load-Interval #2: 5 minute (300 seconds) > input rate 80 bps, 0 pps; output rate 208 bps, 0 pps > RX > 0 unicast packets 5 multicast packets 0 broadcast packets > 5 input packets 762 bytes > 0 jumbo packets 0 storm suppression packets > 0 runts 0 giants 0 CRC 0 no buffer > 0 input error 0 short frame 0 overrun 0 underrun 0 ignored > 0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop > 0 input with dribble 0 input discard > 0 Rx pause > TX > 0 unicast packets 53 multicast packets 0 broadcast packets > 53 output packets 5343 bytes > 0 jumbo packets > 0 output errors 0 collision 0 deferred 0 late collision > 0 lost carrier 0 no carrier 0 babble 0 output discard > 0 Tx pause ifconfig -vvvv ql0 output: > ql0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000 > options=8d07ab<RXCSUM,TXCSUM,VLAN_MTU,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,HWSTATS> > ether 94:f1:28:b3:07:96 > media: Ethernet autoselect (10Gbase-SR <full-duplex>) > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > drivername: ql0 > plugged: SFP/SFP+/SFP28 10G Base-SR (LC) > vendor: OEM PN: SFP-10G85-SR SN: CB220919746 DATE: 2022-09-20 > module temperature: 36.42 C voltage: 3.26 Volts > lane 1: RX power: 0.54 mW (-2.68 dBm) TX bias: 6.40 mA > > SFF8472 DUMP (0xA0 0..127 range): > 03 04 07 10 00 00 00 00 00 00 00 06 67 00 00 00 > 08 02 00 1e 4f 45 4d 20 20 20 20 20 20 20 20 20 > 20 20 20 20 00 00 00 00 53 46 50 2d 31 30 47 38 > 35 2d 53 52 20 20 20 20 41 20 20 20 03 52 00 a7 > 00 1a 00 00 43 42 32 32 30 39 31 39 37 34 36 20 > 20 20 20 20 32 32 30 39 32 30 20 20 68 f0 03 e1 > 00 00 11 b7 ed 31 a4 15 d3 b2 f4 14 38 ed c2 33 > f0 3c 11 00 00 00 00 00 00 00 00 00 a0 be dc ab
(In reply to peter.sopko+freebsd.org from comment #3) > I tried capturing traffic on the ql0 interface when it is not set to promisc mode > using the command you suggested, but there appears to be absolutely no traffic > captured at all... Actually the interface should at least send out LACP packets when it is a member of lagg interface. I have managed to repeat this issue. There're two issue with qlnxe(4) currently are identified. The first one is, the out path ( if_transmit ) lacks ETHER_BPF_MTAP and thus bpf(4) does not have a chance to see the outgoing packets. The second one is, there's a small initialization bug, that when the qlnxe(4) is not flagged up, aka `ifconfig ql0 up`, setup the multicast addresses ( aka SIOCADDMULTI ioctl ) is a noop, and the interface will not be programmed with desired multicast filter, hence the slow protocol multicast traffic ( dest 01:80:c2:00:00:02 ) are all dropped by the interface. That can be identified by the statistic, ``` # sysctl dev.ql.0.hwstat.mac_filter_discards dev.ql.0.hwstat.mac_filter_discards: 284 ``` To workaround the second issue, you may want to put the qlnxe(4) interface into up status before adding it to lagg(4), ``` # ifconfig ql0 up # ifconfig ql1 up # ifconfig lagg0 create # ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 # ifconfig lagg0 up # ifconfig lagg0 lagg0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=8d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,HWSTATS> ether f4:e9:d4:xx:xx:xx hwaddr 00:00:00:00:00:00 laggproto lacp lagghash l2,l3,l4 laggport: ql0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> laggport: ql1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> groups: lagg media: Ethernet autoselect status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> ``` I'm preparing the fix.
(In reply to Zhenlei Huang from comment #4) Thanks, just one more thing (not that in changes anything you wrote, just wanted to let you know for clarity) - I have the following in my rc.conf for testing purposes: > ifconfig_ql0="mtu 9000 up" > ifconfig_ql1="mtu 9000 promisc up" > > cloned_interfaces="lagg0" > > ifconfig_lagg0="inet 172.16.200.30 netmask 255.255.255.0 laggproto lacp laggport ql0 laggport ql1 lacp_fast_timeout up" after a clean boot, ifconfig output clearly states that ql0 has no hwaddr, just ether (which is the same as ql1), and "tcpdump -A -a -nn -s 0 --no-promiscuous-mode -envi ql0" gives no captured traffic at all. executing "ifconfig ql0 up" afterwards makes no differece for me. > ql0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000 > options=8d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,HWSTATS> > ether 94:f1:28:b3:07:96 > media: Ethernet autoselect (10Gbase-SR <full-duplex>) > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > ql1: flags=1028943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC,LOWER_UP> metric 0 mtu 9000 > options=8d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,HWSTATS> > ether 94:f1:28:b3:07:96 > hwaddr 94:f1:28:b3:07:97 > media: Ethernet autoselect (10Gbase-SR <full-duplex>) > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > lagg0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000 > options=8d07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,HWSTATS> > ether 94:f1:28:b3:07:96 > hwaddr 00:00:00:00:00:00 > inet 172.16.200.30 netmask 0xffffff00 broadcast 172.16.200.255 > laggproto lacp lagghash l2,l3,l4 > laggport: ql0 flags=0<> > laggport: ql1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> > groups: lagg > media: Ethernet autoselect > status: active > nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
(In reply to Zhenlei Huang from comment #4) > To workaround the second issue, you may want to put the qlnxe(4) interface into up status before adding it to lagg(4), Update: The above workaround is not right. At least the `allmulti` mode of the interface should be turned on.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=70256d2b86d95a678a63c65b157b9c635f1f4c6a commit 70256d2b86d95a678a63c65b157b9c635f1f4c6a Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:55 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2026-02-06 17:58:16 +0000 qlnxe: Overhaul setting the multicast MAC filters When operating the multicast MAC filters, the current usage of ECORE_FILTER_ADD and ECORE_FILTER_REMOVE are rather misleading. ECORE_FILTER_ADD reads "adding new filter", but it actually removes any existing filters and then addes a new one. ECORE_FILTER_REMOVE reads "removing a filter", but it actually removes all filters. Let's use ECORE_FILTER_REPLACE and ECORE_FILTER_FLUSH instead to avoid confusion. In the current implementation, only one MAC address is passed to ecore_sp_eth_filter_mcast() and any previously installed filters are removed, hence it breaks the multicast function. That can be observed via either assigning new IPv6 addresses to the interface or putting the interface as a member of lagg(4) interface with LACP aggregation protocol. Fix that by calculating the multicast filter bins directly from multicast MAC addresses and replace the filters every time the bins changes. Due to the nature of the multicast filter, which is hash based, a full 1's multicast filter bin means all multicast packets are to be accepted. Thus there's no need to make the vport into allmulti mode when the number of multicast MAC addresses exceeds the limit (ECORE_MAX_MC_ADDRS, 64). Tested with a FastLinQ QL41212HLCU 25GbE adapter, both MFW_Version 8.35.23.0 and 8.59.16.0 are tested. Note: Currently the VF port is set to promiscuous mode unconditionally, and the setting of the multicast MAC filters for VF ports is short-circuited, so the VF port functions as it did. PR: 265857 PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54892 sys/dev/qlnx/qlnxe/ecore_l2.c | 41 ++++---- sys/dev/qlnx/qlnxe/ecore_l2_api.h | 9 +- sys/dev/qlnx/qlnxe/ecore_vf.c | 11 +-- sys/dev/qlnx/qlnxe/qlnx_def.h | 5 +- sys/dev/qlnx/qlnxe/qlnx_os.c | 190 ++++++++------------------------------ 5 files changed, 66 insertions(+), 190 deletions(-)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=968647502ec21464ad3aecc7577ff0e8dfd41693 commit 968647502ec21464ad3aecc7577ff0e8dfd41693 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:54 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2026-02-06 17:56:16 +0000 qlnxe: Allow tapping the TX packets Currently only the packets in the RX path can be captured by tcpdump as the ETHER_BPF_MTAP call in the TX path is missing. Add it so that packets in both directions can be captured. PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54891 sys/dev/qlnx/qlnxe/qlnx_os.c | 1 + 1 file changed, 1 insertion(+)
(In reply to peter.sopko+freebsd.org from comment #5) Hi peter, Sorry for late response. I have just made a serial of fixes / enhancements of the driver qlnxe(4) to the main branch. The issue shall has be fixed. I tested with a FastLinQ QL41212HLCU 25GbE adapter, that might be different with yours. I'll appreciate if you can give it another try and report the result :)
(In reply to Zhenlei Huang from comment #9) Hi, I am very happy to report, that all (LACP, tcpdump, ...) seems to be working, at least from what I can tell from my short round of tests. For the reference I tested with a HPE Eth 10/25Gb 2p 622FLR-SFP28 CNA (identifying itself as a Qlogic 10GbE/25GbE/40GbE PCI CNA (AH) Adapter-Ethernet Function v2.0.112) Great job and thank you very much! One more question - from your experience, is there any chance of this changes making it to 15-stable, or some 15.x-release in the not-so-distant future ?
(In reply to peter.sopko+freebsd.org from comment #10) > Hi, > I am very happy to report, that all (LACP, tcpdump, ...) seems to be working, at > least from what I can tell from my short round of tests. That is great ! > For the reference I tested with a HPE Eth 10/25Gb 2p 622FLR-SFP28 CNA (identifying > itself as a Qlogic 10GbE/25GbE/40GbE PCI CNA (AH) Adapter-Ethernet Function v2.0.112) Thanks! From HPE's specification, https://www.hpe.com/psnow/doc/a00021589enw , that is Cavium QL41402. We know that Cavium acquired QLogic in 2016. > Great job and thank you very much! > > One more question - from your experience, is there any chance of this changes > making it to 15-stable, or some 15.x-release in the not-so-distant future ? I plan to MFC them to stable/15 and stable/14, and partial to stale/13. They will be in future 15.x-RELEASE, and hopefully they will catch up with 14.4-BETA2.
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=425b9cec0b8ce15a6e67d54a73f4f38dc66a4ccc commit 425b9cec0b8ce15a6e67d54a73f4f38dc66a4ccc Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:54 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2026-02-11 10:00:44 +0000 qlnxe: Allow tapping the TX packets Currently only the packets in the RX path can be captured by tcpdump as the ETHER_BPF_MTAP call in the TX path is missing. Add it so that packets in both directions can be captured. PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54891 (cherry picked from commit 968647502ec21464ad3aecc7577ff0e8dfd41693) sys/dev/qlnx/qlnxe/qlnx_os.c | 1 + 1 file changed, 1 insertion(+)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0cfc1145cdfc2a7beeeb7f39ad2722c7053681c0 commit 0cfc1145cdfc2a7beeeb7f39ad2722c7053681c0 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:55 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2026-02-11 10:00:44 +0000 qlnxe: Overhaul setting the multicast MAC filters When operating the multicast MAC filters, the current usage of ECORE_FILTER_ADD and ECORE_FILTER_REMOVE are rather misleading. ECORE_FILTER_ADD reads "adding new filter", but it actually removes any existing filters and then addes a new one. ECORE_FILTER_REMOVE reads "removing a filter", but it actually removes all filters. Let's use ECORE_FILTER_REPLACE and ECORE_FILTER_FLUSH instead to avoid confusion. In the current implementation, only one MAC address is passed to ecore_sp_eth_filter_mcast() and any previously installed filters are removed, hence it breaks the multicast function. That can be observed via either assigning new IPv6 addresses to the interface or putting the interface as a member of lagg(4) interface with LACP aggregation protocol. Fix that by calculating the multicast filter bins directly from multicast MAC addresses and replace the filters every time the bins changes. Due to the nature of the multicast filter, which is hash based, a full 1's multicast filter bin means all multicast packets are to be accepted. Thus there's no need to make the vport into allmulti mode when the number of multicast MAC addresses exceeds the limit (ECORE_MAX_MC_ADDRS, 64). Tested with a FastLinQ QL41212HLCU 25GbE adapter, both MFW_Version 8.35.23.0 and 8.59.16.0 are tested. Note: Currently the VF port is set to promiscuous mode unconditionally, and the setting of the multicast MAC filters for VF ports is short-circuited, so the VF port functions as it did. PR: 265857 PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54892 (cherry picked from commit 70256d2b86d95a678a63c65b157b9c635f1f4c6a) sys/dev/qlnx/qlnxe/ecore_l2.c | 41 ++++---- sys/dev/qlnx/qlnxe/ecore_l2_api.h | 9 +- sys/dev/qlnx/qlnxe/ecore_vf.c | 11 +-- sys/dev/qlnx/qlnxe/qlnx_def.h | 5 +- sys/dev/qlnx/qlnxe/qlnx_os.c | 190 ++++++++------------------------------ 5 files changed, 66 insertions(+), 190 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=87942d7f8fc58e8b4af90ec1050b263005c3d64e commit 87942d7f8fc58e8b4af90ec1050b263005c3d64e Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:55 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2026-02-11 13:48:09 +0000 qlnxe: Overhaul setting the multicast MAC filters When operating the multicast MAC filters, the current usage of ECORE_FILTER_ADD and ECORE_FILTER_REMOVE are rather misleading. ECORE_FILTER_ADD reads "adding new filter", but it actually removes any existing filters and then addes a new one. ECORE_FILTER_REMOVE reads "removing a filter", but it actually removes all filters. Let's use ECORE_FILTER_REPLACE and ECORE_FILTER_FLUSH instead to avoid confusion. In the current implementation, only one MAC address is passed to ecore_sp_eth_filter_mcast() and any previously installed filters are removed, hence it breaks the multicast function. That can be observed via either assigning new IPv6 addresses to the interface or putting the interface as a member of lagg(4) interface with LACP aggregation protocol. Fix that by calculating the multicast filter bins directly from multicast MAC addresses and replace the filters every time the bins changes. Due to the nature of the multicast filter, which is hash based, a full 1's multicast filter bin means all multicast packets are to be accepted. Thus there's no need to make the vport into allmulti mode when the number of multicast MAC addresses exceeds the limit (ECORE_MAX_MC_ADDRS, 64). Tested with a FastLinQ QL41212HLCU 25GbE adapter, both MFW_Version 8.35.23.0 and 8.59.16.0 are tested. Note: Currently the VF port is set to promiscuous mode unconditionally, and the setting of the multicast MAC filters for VF ports is short-circuited, so the VF port functions as it did. PR: 265857 PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54892 (cherry picked from commit 70256d2b86d95a678a63c65b157b9c635f1f4c6a) (cherry picked from commit 0cfc1145cdfc2a7beeeb7f39ad2722c7053681c0) sys/dev/qlnx/qlnxe/ecore_l2.c | 41 ++++---- sys/dev/qlnx/qlnxe/ecore_l2_api.h | 9 +- sys/dev/qlnx/qlnxe/ecore_vf.c | 11 +-- sys/dev/qlnx/qlnxe/qlnx_def.h | 5 +- sys/dev/qlnx/qlnxe/qlnx_os.c | 190 ++++++++------------------------------ 5 files changed, 66 insertions(+), 190 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ddfe98e8ccb120a0a5c42b2288694ecd2b70c80c commit ddfe98e8ccb120a0a5c42b2288694ecd2b70c80c Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:54 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2026-02-11 13:48:09 +0000 qlnxe: Allow tapping the TX packets Currently only the packets in the RX path can be captured by tcpdump as the ETHER_BPF_MTAP call in the TX path is missing. Add it so that packets in both directions can be captured. PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54891 (cherry picked from commit 968647502ec21464ad3aecc7577ff0e8dfd41693) (cherry picked from commit 425b9cec0b8ce15a6e67d54a73f4f38dc66a4ccc) sys/dev/qlnx/qlnxe/qlnx_os.c | 1 + 1 file changed, 1 insertion(+)
A commit in branch releng/14.4 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=572d4096d3cee2811a6a73f0c5a0cc2107f2fa57 commit 572d4096d3cee2811a6a73f0c5a0cc2107f2fa57 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:54 +0000 Commit: Colin Percival <cperciva@FreeBSD.org> CommitDate: 2026-02-11 20:29:22 +0000 qlnxe: Allow tapping the TX packets Currently only the packets in the RX path can be captured by tcpdump as the ETHER_BPF_MTAP call in the TX path is missing. Add it so that packets in both directions can be captured. Approved by: re (cperciva) PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54891 (cherry picked from commit 968647502ec21464ad3aecc7577ff0e8dfd41693) (cherry picked from commit 425b9cec0b8ce15a6e67d54a73f4f38dc66a4ccc) (cherry picked from commit ddfe98e8ccb120a0a5c42b2288694ecd2b70c80c) sys/dev/qlnx/qlnxe/qlnx_os.c | 1 + 1 file changed, 1 insertion(+)
A commit in branch releng/14.4 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2f4767601230005d77fd57ed287869d882604e96 commit 2f4767601230005d77fd57ed287869d882604e96 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:55 +0000 Commit: Colin Percival <cperciva@FreeBSD.org> CommitDate: 2026-02-11 20:29:25 +0000 qlnxe: Overhaul setting the multicast MAC filters When operating the multicast MAC filters, the current usage of ECORE_FILTER_ADD and ECORE_FILTER_REMOVE are rather misleading. ECORE_FILTER_ADD reads "adding new filter", but it actually removes any existing filters and then addes a new one. ECORE_FILTER_REMOVE reads "removing a filter", but it actually removes all filters. Let's use ECORE_FILTER_REPLACE and ECORE_FILTER_FLUSH instead to avoid confusion. In the current implementation, only one MAC address is passed to ecore_sp_eth_filter_mcast() and any previously installed filters are removed, hence it breaks the multicast function. That can be observed via either assigning new IPv6 addresses to the interface or putting the interface as a member of lagg(4) interface with LACP aggregation protocol. Fix that by calculating the multicast filter bins directly from multicast MAC addresses and replace the filters every time the bins changes. Due to the nature of the multicast filter, which is hash based, a full 1's multicast filter bin means all multicast packets are to be accepted. Thus there's no need to make the vport into allmulti mode when the number of multicast MAC addresses exceeds the limit (ECORE_MAX_MC_ADDRS, 64). Tested with a FastLinQ QL41212HLCU 25GbE adapter, both MFW_Version 8.35.23.0 and 8.59.16.0 are tested. Note: Currently the VF port is set to promiscuous mode unconditionally, and the setting of the multicast MAC filters for VF ports is short-circuited, so the VF port functions as it did. Approved by: re (cperciva) PR: 265857 PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54892 (cherry picked from commit 70256d2b86d95a678a63c65b157b9c635f1f4c6a) (cherry picked from commit 0cfc1145cdfc2a7beeeb7f39ad2722c7053681c0) (cherry picked from commit 87942d7f8fc58e8b4af90ec1050b263005c3d64e) sys/dev/qlnx/qlnxe/ecore_l2.c | 41 ++++---- sys/dev/qlnx/qlnxe/ecore_l2_api.h | 9 +- sys/dev/qlnx/qlnxe/ecore_vf.c | 11 +-- sys/dev/qlnx/qlnxe/qlnx_def.h | 5 +- sys/dev/qlnx/qlnxe/qlnx_os.c | 190 ++++++++------------------------------ 5 files changed, 66 insertions(+), 190 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=281d578e9ff56412bedbf7884fa097e5e59438da commit 281d578e9ff56412bedbf7884fa097e5e59438da Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:54 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2026-02-24 10:15:37 +0000 qlnxe: Allow tapping the TX packets Currently only the packets in the RX path can be captured by tcpdump as the ETHER_BPF_MTAP call in the TX path is missing. Add it so that packets in both directions can be captured. PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54891 (cherry picked from commit 968647502ec21464ad3aecc7577ff0e8dfd41693) (cherry picked from commit 425b9cec0b8ce15a6e67d54a73f4f38dc66a4ccc) (cherry picked from commit ddfe98e8ccb120a0a5c42b2288694ecd2b70c80c) sys/dev/qlnx/qlnxe/qlnx_os.c | 1 + 1 file changed, 1 insertion(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=091a1e7d21c9b2cbd7dbe89335b08d4d50fab96e commit 091a1e7d21c9b2cbd7dbe89335b08d4d50fab96e Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2026-02-06 17:52:55 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2026-02-24 10:15:38 +0000 qlnxe: Overhaul setting the multicast MAC filters When operating the multicast MAC filters, the current usage of ECORE_FILTER_ADD and ECORE_FILTER_REMOVE are rather misleading. ECORE_FILTER_ADD reads "adding new filter", but it actually removes any existing filters and then addes a new one. ECORE_FILTER_REMOVE reads "removing a filter", but it actually removes all filters. Let's use ECORE_FILTER_REPLACE and ECORE_FILTER_FLUSH instead to avoid confusion. In the current implementation, only one MAC address is passed to ecore_sp_eth_filter_mcast() and any previously installed filters are removed, hence it breaks the multicast function. That can be observed via either assigning new IPv6 addresses to the interface or putting the interface as a member of lagg(4) interface with LACP aggregation protocol. Fix that by calculating the multicast filter bins directly from multicast MAC addresses and replace the filters every time the bins changes. Due to the nature of the multicast filter, which is hash based, a full 1's multicast filter bin means all multicast packets are to be accepted. Thus there's no need to make the vport into allmulti mode when the number of multicast MAC addresses exceeds the limit (ECORE_MAX_MC_ADDRS, 64). Tested with a FastLinQ QL41212HLCU 25GbE adapter, both MFW_Version 8.35.23.0 and 8.59.16.0 are tested. Note: Currently the VF port is set to promiscuous mode unconditionally, and the setting of the multicast MAC filters for VF ports is short-circuited, so the VF port functions as it did. PR: 265857 PR: 290973 Reviewed by: kbowling MFC after: 5 days Differential Revision: https://reviews.freebsd.org/D54892 (cherry picked from commit 70256d2b86d95a678a63c65b157b9c635f1f4c6a) (cherry picked from commit 0cfc1145cdfc2a7beeeb7f39ad2722c7053681c0) (cherry picked from commit 87942d7f8fc58e8b4af90ec1050b263005c3d64e) sys/dev/qlnx/qlnxe/ecore_l2.c | 41 ++++---- sys/dev/qlnx/qlnxe/ecore_l2_api.h | 9 +- sys/dev/qlnx/qlnxe/ecore_vf.c | 11 +-- sys/dev/qlnx/qlnxe/qlnx_def.h | 5 +- sys/dev/qlnx/qlnxe/qlnx_os.c | 190 ++++++++------------------------------ 5 files changed, 66 insertions(+), 190 deletions(-)
I'm closing this, as the fix is now in all supported stable branches.
*** Bug 265857 has been marked as a duplicate of this bug. ***