OS throws away large packets

Mr Y yonyossef.lists at gmail.com
Tue May 6 07:45:13 UTC 2008


>
>  > >>> Hi all,
> > >>>
> > >>> I'm trying to implement Large Recieve Offload for an
> > >>>
> > >> Ethernet driver
> > >>
> > >>> 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
> > >>>
> > >> a cluster
> > >>
> > >>> of MCLBYTES bytes. They are linked by the m_next pointer.
> > >>> The first packet being thrown away is 2945 bytes long.
> > >>>
> > >> Wireshark shows
> > >>
> > >>> 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.
> > >>>
> > >>>
> > >> Hi Yony,
> > >>
> > >> I seem to remember some discussion about this list last
> > year see the
> > >> following threads:
> > >>
> > >>
> > >>
> > >
> >
> http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015250.htm
> l
> > >
> > >
> >
> http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.htm
> l
> > >
> > > >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
> > >
> > >> enforced further up the stack or at least that seamed to
> > be the case
> > >>
> > > with the bce driver.
> > >
> > >> Hope this is helpful,
> > >>
> > >> Tom
> > >>
> > >
> > > Hi Tom,
> > >
> > > >From what I understand these threads are referring to the bce
> > > >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
> > > driver and reports a good packet (and 2945 bytes long), I assume my
> > > driver functionality is ok. From what I know tcpdump is supposed to
> > > 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
> > > mbuf chains, or a kernel tcp parameter. Is the tcp stack
> > submitted to
> > > the mtu somehow?
> > >
> > >
> > I don't see where you've identified what version of the os you're
> > working with.  There's a check in the 802.3 input path on earlier
> > systems to discard frames >mtu.  This was removed not too long ago
> > with LRO in mind; check the history of sys/net/if_ethersubr.c.
> >
> >     Sam
> >
>
> 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.
>

The problem was in my packet, after I put some traces in netinet/ip_input.c
I found out my m_pkthdr.len was not properly updated.

Thanks


More information about the freebsd-questions mailing list