bce(4) sees all incoming frames as 2026 bytes in length

pluknet pluknet at gmail.com
Thu Apr 30 13:11:29 UTC 2009


2009/4/30 Nikolay Denev <ndenev at gmail.com>:
> On Apr 29, 2009, at 7:04 PM, pluknet wrote:
>
>> 2009/4/29 Niki Denev <ndenev at 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


More information about the freebsd-net mailing list