Return to BSD News archive
Xref: sserve comp.os.386bsd.bugs:1150 comp.unix.bsd:12301
Newsgroups: comp.os.386bsd.bugs,comp.unix.bsd
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!olivea!uunet!emba-news.uvm.edu!trantor.emba.uvm.edu!wollman
From: wollman@trantor.emba.uvm.edu (Garrett Wollman)
Subject: Re: Incorrect input packet count for ethernet
Message-ID: <1993Jul20.194515.19199@emba.uvm.edu>
Sender: news@emba.uvm.edu
Organization: University of Vermont, EMBA Computer Facility
References: <22f8dr$85s@tribune.usask.ca> <CGD.93Jul19202440@erewhon.CS.Berkeley.EDU> <CGD.93Jul19211023@erewhon.cs.berkeley.edu>
Date: Tue, 20 Jul 1993 19:45:15 GMT
Lines: 44
[This isn't really {386,Net}BSD-specific, so think about where your
followups go.]
In article <CGD.93Jul19211023@erewhon.cs.berkeley.edu> cgd@erewhon.CS.Berkeley.EDU (Chris G. Demetriou) writes:
[Chris is talking about how ether_input() handles the byte input count on
Ether interfaces, but the netif driver handles the packet input count.]
>to say that it's "supposed" to be handled that way would imply
>that that's the correct solution to the problem, and i'm not sure
>about that...
I would argue that this is the correct solution, for the simple reason
that ether_input() doesn't actually know how many packets were
received; it only knows that the driver has passed up one object which
it thinks represents one datagram. Now, as it happens, under Ethernet
there is always a one-to-one correspondence. However, with certain
other network technologies (consider, for example, ATM), this is not
the case. So, I would agree with the current arrangement; the
specific interface driver is responsible for counting the number of
packets it specifically has handled, but the ``generic'' driver
support routines should take care of the byte counts. (Consider, for
example, a naive ATM interface which just hands off every cell to
atm_input(), a hypothetical routine to take care of AAL5. The
interface driver knows how many cells it has handled, but it doesn't
know how many actual bytes of data have passed through.)
Now to bring things back towards Ethernet, consider a hypothetical
network interface that handles data in small chunks, but looks to ULPs
as if it were a real Ethernet(tm). Such a device would need the same
split in functionality as the naive ATM interface I suggested above.
So, the way functionality is currently split makes perfect sense to
me.
I am cross-posting this to comp.unix.bsd in the hope that the original
authors of that code might see it and explain how far off-base I am...
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman | It is a bond more powerful than absence. We like people
UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant