Date: Thu, 30 Apr 2009 15:04:19 +0300 From: Nikolay Denev <ndenev@gmail.com> To: freebsd-net@freebsd.org Subject: bce(4) and lagg(4) fix [was: bce(4) sees all incoming frames as 2026 bytes in length] Message-ID: <5FD800FE-23E5-482E-8491-564FE52D91D5@gmail.com> In-Reply-To: <FAC395EB-BEE6-4981-85D2-82ADFC2DF441@gmail.com> References: <5E915E92-2B82-4331-9493-739568CC6E8C@gmail.com> <a31046fc0904290659h3c831abcy14318b73c1462068@mail.gmail.com> <2e77fc10904290733m4858172ayd96654f3a9a3a8a@mail.gmail.com> <a31046fc0904290904x796a7d44ne66514f777d2237f@mail.gmail.com> <FAC395EB-BEE6-4981-85D2-82ADFC2DF441@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-495-792854591 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 <ndenev@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 ) >>> >>> 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> >>> 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 : >>> >>> 16:27:32.593808 00:22:19:yy:yy:yy > 00:22:19:xx:xx:xx, ethertype >>> IPv4 >>> (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 >>> 16:27:32.593817 00:22:19:xx:xx:xx > 00:22:19:yy:yy:yy, ethertype >>> IPv4 >>> (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 >> >> Ok, now I see. A link level length is 2026 for me too for some sort >> of packets >> (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 > > > I think I got it. > > 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. > > After I added this : > > m0->m_pkthdr.len = m0->m_len = pkt_len; > > 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. Regards, Niki Denev --Apple-Mail-495-792854591 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (Darwin) iEYEARECAAYFAkn5k8MACgkQHNAJ/fLbfrkOjgCeJr2oVcHvgZPcyJ+O+M+rlRj1 nEkAnAnZke4evdELE8LNUvnZFN0b2W2G =iMjj -----END PGP SIGNATURE----- --Apple-Mail-495-792854591--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5FD800FE-23E5-482E-8491-564FE52D91D5>