Date: Thu, 23 Dec 1999 02:00:26 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: current@freebsd.org, julian@whistle.com, scottm@CS.UCLA.EDU, jlemon@americantv.com, brad@shub-internet.org, jabley@patho.gen.nz, phk@critter.freebsd.dk, wollman@khavrinen.lcs.mit.edu Subject: Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents) Message-ID: <199912230700.CAA10582@skynet.ctr.columbia.edu> In-Reply-To: <199912230641.WAA16876@apollo.backplane.com> from "Matthew Dillon" at Dec 22, 99 10:41:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Matthew Dillon
had to walk into mine and say:
> (taking this off -current)
>
> apollo# linktest -s 51 -f1 lander 1-51 byte payload -> errors
> lander# linktest -s 51 -f1 apollo
>
> apollo# linktest -s 52 -f1 lander 52+ byte payload -> no errors
> lander# linktest -s 52 -f1 apollo
>
>
> You know, this kinda sounds like a jabber lockup.
>
> Bill, are you following the *MINIMUM* ethernet frame size specification
> for ethernet?
*sigh* No, I've been living on Mars since 1975 and we don't get IEEE spec
documents up here.
Yes, I know there's a minimum frame length of 60 bytes. And the rl_encap()
routine has the following code:
/* Pad frames to at least 60 bytes. */
if (m_head->m_pkthdr.len < RL_MIN_FRAMELEN) {
m_head->m_pkthdr.len +=
(RL_MIN_FRAMELEN - m_head->m_pkthdr.len);
m_head->m_len = m_head->m_pkthdr.len;
}
The RealTek doesn't autopad, so you have to handle it manually. You're
only allowed one DMA buffer per transmission, so outbound packets are
coalesced into a single mbuf cluster buffer in rl_encap(). A cluster
buffer is always 2K, and frames can never be larger than 1514 bytes, so
we know there'll always be plenty of room. In the case of frames less
60 bytes, I just adjust bump up m_pkthdr.len and m_len. This adjuster
length gets used later in rl_start() when transmission is triggered.
Incidentally, you should be using tcpdump -n -e -i rl0 to measure the
actual frame length of failing and succeeding transmissions: that's
usually a much better indicator of what might be going wrong. You could
calculate it from the data buffer length, but I suck at math; I find it's
easier just to monitor the offending frames.
-Bill
=============================================================================
-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
=============================================================================
"It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=============================================================================
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912230700.CAA10582>