2009/4/30 Nikolay Denev <nde...@gmail.com>: > 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 ) >>> >>> 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. >
JFYI In 7.1-R driver version there was length updating and it seems to be lost in 7.2-R. /* Skip over the l2_fhdr when passing the data up the s m_adj(m, sizeof(struct l2_fhdr) + ETHER_ALIGN); /* Adjust the packet length to match the received data. m->m_pkthdr.len = m->m_len = len; /* Send the packet to the appropriate interface. */ m->m_pkthdr.rcvif = ifp; > 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. At least it can be ifndef'ed out in ZERO_COPY_SOCKETS case. @@ -5926,6 +5926,11 @@ goto bce_rx_int_next_rx; } +#ifndef ZERO_COPY_SOCKETS + /* Set the total packet length. */ + m0->m_pkthdr.len = m0->m_len = pkt_len; +#endif + /* Send the packet to the appropriate interface. */ m0->m_pkthdr.rcvif = ifp; -eop- -- wbr, pluknet _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"