Date: Mon, 2 Sep 2002 14:44:52 -0500 From: "Justin C. Walker" <justin@mac.com> To: arch@FreeBSD.ORG Subject: Re: Ethernet packet padding: How much is legal? Message-ID: <732CD7A3-BEAC-11D6-92CC-000393575CAC@mac.com> In-Reply-To: <20020902140522.W281-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, September 2, 2002, at 02:19 , Mike Silbersack wrote:
> This may be offtopic for the list, but I know that some of you guys will
> know the answer to this question. :)
>
> Despite the overall success of the recent patches to the if_vr
> driver, Thomas Nystrom and Jean Delvare have continued to search for the
> root of the problems in the if_vr hardware.
>
> 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:
>
>
> if (m_head->m_len < VR_MIN_FRAMELEN) {
> m_new->m_pkthdr.len += VR_MIN_FRAMELEN -
> m_new->m_len;
> m_new->m_len = m_new->m_pkthdr.len;
> }
> + if ((m_head->m_len > 400) && (m_head->m_len < 800)) {
> + m_new->m_pkthdr.len = 800;
> + m_new->m_len = m_new->m_pkthdr.len;
> + }
>
> Thomas says that the above preliminary patch seems to solve the problem,
> so it looks like a workable solution if we can more exactly determine
> the
> range in which we need to pad. (And perhaps only pad if the preceeding
> packet is a full size frame, etc - this is still being researched.)
>
> Anyway, now to the real question: Is adding arbitrary padding like this
> going to break anything? IP seems content, but will other protocols be
> broken by extra ethernet padding? Although we don't support too many
> protocols, the card could be passing all sorts of packets if it is used
> for bridging.
I'll hazard a guess that it's OK, unless there are protocols that live
or die by the inferred length of a packet, rather than information in
the packet itself. I don't know of any off-hand. I'm assuming that
your code (above) doesn't actually affect internal length indicators,
and just transmits extra bytes.
For ethernet-2 (like IP/ARP), I can't say for sure that encapsulated
protocols all carry their own lengths. IP does (AFAIK; most transport
protocols seem to include their own length), and ARP is fixed-size.
For 802.x, I believe that the length of the media frame is always
present (as opposed to the network packet, as in IP).
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.
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.
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics | Men are from Earth.
| Women are from Earth.
| Deal with it.
*--------------------------------------*-------------------------------*
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?732CD7A3-BEAC-11D6-92CC-000393575CAC>