Date: Fri, 08 Oct 2004 14:38:01 -0700 From: Julian Elischer <julian@elischer.org> To: Giorgos Keramidas <keramida@freebsd.org> Cc: Gleb Smirnoff <glebius@freebsd.org> Subject: Re: Calling m_pullup in ether_input Message-ID: <416708B9.6090205@elischer.org> In-Reply-To: <20041008205117.GA7818@gothmog.gr> References: <20041008151515.GA3136@orion.daedalusnetworks.priv> <20041008203434.GA2770@cell.sick.ru> <20041008205117.GA7818@gothmog.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos Keramidas wrote: >On 2004-10-09 00:34, Gleb Smirnoff <glebius@freebsd.org> wrote: > > >>On Fri, Oct 08, 2004 at 06:15:15PM +0300, Giorgos Keramidas wrote: >>G> In ether_input() we unconditionaly discard the mbufs whose m_len is less than >>G> ETHER_HDR_LEN. A bit higher M_PKTHDR has been checked but the check made >>G> before discarding the frame doesn't pay attention to the m->m_pkthdr.len (the >>G> total packet length). >> >>In my humble opinion, all Ethernet device drivers are intentionally written >>in such a way that they always pass an mbuf with contigous Ethernet header >>to ether_input(). >> I'm not convinced this is true for jumbo backets. >> >> > >I know, but thanks for verifying what I had understood so far :-) > > > >>Why did you write this patch? Do you really have packet loss? >> >> > >Not really. Just trying to see if there _was_ any packet loss first. >After running for several hours, the counters are still zero. I think >this means the case of dropped packets would be so rare that there's no >real reason to worry too much about lost packets. > > > >>G> I am trying to find out how often this happens, by using the attached patch to >>G> count the number of small frames received in ether_input() and the number of >>G> failed m_pullup() attempts that result from that. >> >>And what results do you have? >> >> > >I'll keep this change in my workstation for a week or so. No signs of >dropped packets yet, though. > > > >>G> Does this change seem reasonable as an instrumentation of the particular >>G> problem or am I unknowingly breaking something in the way ether_input() is >>G> supposed to work? >> >>AFAIK, this patch does not break anything but just adds more processing. >> >> > >Thanks for the reply. I'm (somewhat slowly) learning more about the way >the networking code. A little more processing is a small penalty to pay >for trying out things. > >- Giorgos > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416708B9.6090205>