Date: Tue, 29 Apr 2008 20:14:18 +0300 From: "Yehonatan Yossef" <yoniy@mellanox.co.il> To: "Sam Leffler" <sam@freebsd.org> Cc: Tom Judge <tom@tomjudge.com>, freebsd-net@freebsd.org, Liran Liss <liranl@mellanox.co.il>, freebsd-questions@freebsd.org, Mr Y <yonyossef.lists@gmail.com> Subject: RE: OS throws away large packets Message-ID: <6C2C79E72C305246B504CBA17B5500C903E6C7C2@mtlexch01.mtl.com> In-Reply-To: <48174A0D.1090302@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=20 > -----Original Message----- > From: Sam Leffler [mailto:sam@freebsd.org]=20 > Sent: Tuesday, April 29, 2008 7:17 PM > To: Yehonatan Yossef > Cc: Tom Judge; Mr Y; freebsd-net@freebsd.org;=20 > freebsd-questions@freebsd.org; Liran Liss > Subject: Re: OS throws away large packets >=20 > Yehonatan Yossef wrote: > > =20 > > > > =20 > >> -----Original Message----- > >> From: Tom Judge [mailto:tom@tomjudge.com] > >> Sent: Monday, April 28, 2008 8:21 PM > >> To: Mr Y > >> Cc: freebsd-questions@freebsd.org; freebsd-net@freebsd.org > >> Subject: Re: OS throws away large packets > >> > >> Mr Y wrote: > >> =20 > >>> 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=20 > 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=20 > year see the=20 > >> following threads: > >> > >> > >> =20 > >=20 > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.h > > tm > > l > > =20 > >=20 > http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.h > > tm > > 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=20 > defined in=20 > > the nic driver rather than > > =20 > >> enforced further up the stack or at least that seamed to=20 > 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=20 > allocation size. Am=20 > > I correct? > > In my case I'm not trying to receive packets >MTU from the=20 > HW, but to=20 > > chain mbuf clusters, each is MCLBYTES long, and pass the=20 > mbuf chain to=20 > > 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=20 > driver (at net=20 > > 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=20 > submitted to=20 > > the mtu somehow? > > > > =20 > I don't see where you've identified what version of the os=20 > you're working with. There's a check in the 802.3 input path=20 > on earlier systems to discard frames >mtu. This was removed=20 > not too long ago with LRO in mind; check the history of=20 > sys/net/if_ethersubr.c. >=20 > Sam >=20 Hi Sam, I have mentioned working on 6.3. FreeBSD 6.2 had this check in if_ethersubr.c / ether_input: 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 } 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C2C79E72C305246B504CBA17B5500C903E6C7C2>