Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Oct 2004 23:51:17 +0300
From:      Giorgos Keramidas <keramida@freebsd.org>
To:        Gleb Smirnoff <glebius@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Calling m_pullup in ether_input
Message-ID:  <20041008205117.GA7818@gothmog.gr>
In-Reply-To: <20041008203434.GA2770@cell.sick.ru>
References:  <20041008151515.GA3136@orion.daedalusnetworks.priv> <20041008203434.GA2770@cell.sick.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041008205117.GA7818>