bce(4) and lagg(4) fix [was: bce(4) sees all incoming frames as 2026 bytes in length]

[Nikolay Denev]

On Apr 30, 2009, at 2:56 PM, Nikolay Denev wrote:

On Apr 29, 2009, at 7:04 PM, pluknet wrote:

2009/4/29 Niki Denev <nde...@gmail.com>:

bce1: <Broadcom NetXtreme II BCM5708 1000Base-T (B2)> mem
0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3
bce1: Ethernet address: 00:22:19:xx:xx:xx
bce1: [ITHREAD]
bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C
(0x04040105); Flags( MFW MSI )


      ether 00:22:19:xx:xx:xx
      inet 10.18.2.1 netmask 0xffffff00 broadcast 10.18.2.255
      media: Ethernet autoselect (1000baseTX <full-duplex>)
      status: active

And here is a tcpdump that shows the problem :


(0x0800), length 2026: (tos 0x0, ttl 64, id 45347, offset 0, flags
[none], proto ICMP (1), length 84) 10.18.2.2 > 10.18.2.1: ICMP echo
request, id 13578, seq 36, length 64

(0x0800), length 98: (tos 0x0, ttl 64, id 18415, offset 0, flags
[none], proto ICMP (1), length 84) 10.18.2.1 > 10.18.2.2: ICMP echo
reply, id 13578, seq 36, length 64

bce1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options = 1bb <RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4> 16:27:32.593808 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype IPv4 16:27:32.593817 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype IPv4

(in opposite to proto's len where all is ok).

Mine nic is <Broadcom NetXtreme II BCM5708 1000Base-T (B2)>
(same as yours).

Looks like a regression.
I just also tested 7.1-R and it shows expected LL-length.


--
wbr,
pluknet

Ok, now I see. A link level length is 2026 for me too for some sort of packets

I think I got it.



After I added this :

   m0->m_pkthdr.len = m0->m_len = pkt_len;







Regards,
Niki Denev

It seems that the mbuf fields m_pkthdr.len and m_len are not updated to the real packet size pkt_len. Well, actually they are updated, but only if we have ZERO_COPY_SOCKETS defined. at about line 5930 in if_bce.c, the frame length reported by tcpdump seems correct. P.S.: I guess this could be the cause for the lagg(4) over bce(4) problems too? P.S.2: This fix will probably break the ZERO_COPY_SOCKETS case, but should be fairly easy to make it a "proper" fix.

Regards,
Niki Denev

I can confirm that with this fix I was able to create lagg(4) interface in "failover" mode with only one member, a bce(4) interface, and it seems to work OK.

PGP.sig
Description: This is a digitally signed message part