Date: Mon, 02 Sep 2002 17:56:37 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Justin C. Walker" <justin@mac.com> Cc: arch@FreeBSD.ORG Subject: Re: Ethernet packet padding: How much is legal? Message-ID: <3D7408C5.21CEBF2C@mindspring.com> References: <732CD7A3-BEAC-11D6-92CC-000393575CAC@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Justin C. Walker" wrote:
> On Monday, September 2, 2002, at 02:19 , Mike Silbersack wrote:
> > In short, they've found that if a 1500 byte packet + a small fragment
> > adding up to approximately 2K are sent in quick succession, the small
> > fragment will be dropped. This appears to be a bug in the Via Rhine
> > hardware, so we're brainstorming on ways to work around this problem.
> >
> > One option we're seriously looking at is padding all ethernet packets
> > within a certain size (400 - 600 bytes in size) up to 600 bytes. This
> > would be done in vr_encap just as padding to minimum packet size is done
> > currently:
1) The patch says "800", not "600"; is this is mistake, or is it
just a case of "the more bytes, the merrier"?
> > + if ((m_head->m_len > 400) && (m_head->m_len < 800)) {
> > + m_new->m_pkthdr.len = 800;
[ ... ]
> One thing to be wary of is IPX - it's got a zillion frame formats (OK,
> four) and at least one doesn't include a media frame length.
16bit NE1000's had the problem that, if you sent an odd number
of bytes, that it would byte-swap the last byte with garbage
(as far as I know, they still have this problem, unless someone
has waved a wand 8-)).
It was common practice to fix this in the driver to force sending
of an extra byte for odd length packets, when doing the DMA, so
that the length was 16bit aligned.
This is true for the Windows, DOS, and UnixWare drivers, as they
were shipped by Novell.
> Of course, there's always the question of whether a receiving driver
> will get bent out of shape if the stated (in the frame) length is
> smaller than the received length.
I was worried about this, too. One byte is generally not a
problem, since there are receiver alignment issues, as well,
that are "magically" taken care of by allocating the extra
space.
The only possible issue with such a massive pad (599 bytes as
spec'ed, 799 bytes as written) is receives directly to user
buffers. I don't think this is going to be a problem unless
you have a network processor board, which knows about CP
streams before doing the transfer to the user buffer, based
on which stream the data is destined for (preemptive protocol
processing).
Probably the best person to ask on this would be CGD of NetBSD
fame, who is currently working at Broadcom, which acquired
sibyte <http://www.sibyte.com/>; (a product wihch does processing
like this).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D7408C5.21CEBF2C>