OS throws away large packets

[Yehonatan Yossef]

> -----Original Message-----
> From: Sam Leffler [mailto:sam at freebsd.org] 
> Sent: Tuesday, April 29, 2008 7:17 PM
> To: Yehonatan Yossef
> Cc: Tom Judge; Mr Y; freebsd-net at freebsd.org; 
> freebsd-questions at freebsd.org; Liran Liss
> Subject: Re: OS throws away large packets
> 
> Yehonatan Yossef wrote:
> >  
> >
> >   
> >> -----Original Message-----
> >> From: Tom Judge [mailto:tom at tomjudge.com]
> >> Sent: Monday, April 28, 2008 8:21 PM
> >> To: Mr Y
> >> Cc: freebsd-questions at freebsd.org; freebsd-net at freebsd.org
> >> Subject: Re: OS throws away large packets
> >>
> >> Mr Y wrote:
> >>     
> >>> 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.h
> > tm
> > l
> >   
> > 
> http://lists.freebsd.org/pipermail/freebsd-net/2007-September/015350.h
> > tm
> > 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.