Date: Tue, 29 Apr 2008 20:18:17 +0300 From: "Yehonatan Yossef" <yoniy@mellanox.co.il> To: "Sam Leffler" <sam@freebsd.org> Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, Liran Liss <liranl@mellanox.co.il> Subject: RE: OS throws away large packets Message-ID: <6C2C79E72C305246B504CBA17B5500C903E6C7C6@mtlexch01.mtl.com>
next in thread | raw e-mail | index | archive | help
> >>> Hi all, > >>> > >>> I'm trying to implement Large Recieve Offload for an > >>> =20 > >> Ethernet driver > >> =20 > >>> on FreeBSD 6.3, but all my >MTU packets are being thrown > by the OS. > >>> I'm using mbuf chains in this imlpementation, each mbuf is > >>> =20 > >> a cluster > >> =20 > >>> of MCLBYTES bytes. They are linked by the m_next pointer. > >>> The first packet being thrown away is 2945 bytes long.=20 > >>> =20 > >> Wireshark shows > >> =20 > >>> the packet that is being passed to the OS is correct. > >>> > >>> Do I need to set some OS parameter to make it recieve mbuf chains? > >>> > >>> Please help. > >>> > >>> =20 > >> Hi Yony, > >> > >> I seem to remember some discussion about this list last > year see the > >> following threads: > >> > >> > >> =20 > >=20 > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm l > > =20 > >=20 > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm l > > =20 > > >From my limited reading of these threads just now and possibly bad > > memory. It would seem that the MRU to MTU relationship is > defined in > > the nic driver rather than > > =20 > >> enforced further up the stack or at least that seamed to > be the case > >> =20 > > with the bce driver. > > =20 > >> Hope this is helpful, > >> > >> Tom > >> =20 > > > > Hi Tom, > > > > >From what I understand these threads are referring to the bce=20 > > >hardware > > configuration (bus configuration) and driver mbuf > allocation size. Am > > I correct? > > In my case I'm not trying to receive packets >MTU from the > HW, but to > > chain mbuf clusters, each is MCLBYTES long, and pass the > mbuf chain to > > the OS. > > Since tcpdump (analyzed by wireshark) catches the packets above the=20 > > driver and reports a good packet (and 2945 bytes long), I assume my=20 > > driver functionality is ok. From what I know tcpdump is supposed to=20 > > immitate the way the stack sees the packet, yet it is discarded. > > My logic says there is an OS parameter handled by the > driver (at net > > device init time for example) that will set the OS to receive large=20 > > mbuf chains, or a kernel tcp parameter. Is the tcp stack > submitted to > > the mtu somehow? > > > > =20 > I don't see where you've identified what version of the os you're=20 > working with. There's a check in the 802.3 input path on earlier=20 > systems to discard frames >mtu. This was removed not too long ago=20 > with LRO in mind; check the history of sys/net/if_ethersubr.c. >=20 > Sam >=20 =20 Hi Sam, I have mentioned working on 6.3. =20 FreeBSD 6.2 had this check in if_ethersubr.c / ether_input: =20 539 if (m->m_pkthdr.len > 540 ETHER_MAX_FRAME(ifp, etype, m->m_flags & M_HASFCS)) { 541 if_printf(ifp, "discard oversize frame " 542 "(ether type %x flags %x len %u > max %lu)\n", 543 etype, m->m_flags, m->m_pkthdr.len, 544 ETHER_MAX_FRAME(ifp, etype, 545 m->m_flags & M_HASFCS)); 546 ifp->if_ierrors++; 547 m_freem(m); 548 return; 549 } =20 Patching it was explained by neterion in http://trac.neterion.com/cgi-bin/trac.cgi/wiki/FreeBSD. This check no longer exists in 6.3, nor any other oversize packet handling (I couldn't find any so far). I also get no error prints from the OS. =20 =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C2C79E72C305246B504CBA17B5500C903E6C7C6>