Date: Sat, 5 Sep 1998 07:45:07 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: hackers@FreeBSD.ORG Subject: Re: Questions for networking gurus Message-ID: <199809050545.HAA13946@labinfo.iet.unipi.it> In-Reply-To: <199809042326.TAA13218@skynet.ctr.columbia.edu> from "Bill Paul" at Sep 4, 98 07:26:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm trying to work out a packet reception strategy for the RealTek
> ethernet controller. The RealTek chip is a bus master, which normally
are you talking about some 100Mbit card ?
> is a good thing because with the right sort of interface you can eliminate
> buffer copies within the driver code. Unfortunately, the RealTek is designed
> in such a way that it's almost impossible to avoid buffer copies even with
...
> The RealTek chip works roughly as follows. The driver allocates a buffer
> area of 8K, 16K, 32K or 64K in size, depending on the setting of certain
to summarise, a circular buffer with variable block sizes much like
the one used in the audio driver :)
> One possibly alternative was proposed to me recently by Matthew Dodd,
> which is to use the external data pointers in mbufs. The idea works
right, although i'd do it somewhat differently, i.e. before the buffer
wraps around, reallocate a buffer area using a fresh set of clusters.
I see only one problem in case the mbuf cluster allocator cannot
return you a contiguous area of the desired size (8..64K) -- but
there are several ways to possible fix this:
* modify the mbuf allocator to make its granularity at least 8K
* depending on how the controller works, you might be able to
tell the controller that you cannot really start at the beginning,
or you have to stop before the end;
* if everything else fails, you can still resort to a static buffer
when the contiguous allocation fails and copy data back to mbufs
in that case.
> 1) Does using external data regions with mbufs like this actually work?
> I know it works with mbuf clusters, but that's sort of a special case.
> I remember reading somewhere, possibly in TCP/IP Illustrated Vol. 2,
> that there were bugs that prevented this from working correctly 100%
> of the time except for the mbuf cluster case. Has this been fixed, or
> are there still pitfalls?
i dont know much on the above, but for sure clusters have a reference
count at least which is held externally to the cluster, and the pointer
to the reference count is derived by playing tricks on the cluster
pointer. So, it doesn't work well if the external pointer is not to a
cluster.
> 2) What's the longtest time than an mbuf chain with received packet data
> will survive inside the kernel? The driver has to allocate enough
impossible to know. Could be several minutes e.g. if the buffer remains
trapped in the socket layer.
> So, does this scheme sound sensible or should I just swallow my pride
> and settle for using m_devget(). It would be nice to find a way to
see above. I think the CPU savings are worthwhile, and the memory waste
by changing the allocator granularity is not that terrible.
cheers
luigi
-----------------------------+--------------------------------------
Luigi Rizzo | Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it | Universita' di Pisa
tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/
_____________________________|______________________________________
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809050545.HAA13946>