From owner-freebsd-arch Mon Sep 2 17:57:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04E0F37B400 for ; Mon, 2 Sep 2002 17:57:42 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D2F643E6E for ; Mon, 2 Sep 2002 17:57:41 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0137.cvx40-bradley.dialup.earthlink.net ([216.244.42.137] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17m20f-0001Mp-00; Mon, 02 Sep 2002 17:57:38 -0700 Message-ID: <3D7408C5.21CEBF2C@mindspring.com> Date: Mon, 02 Sep 2002 17:56:37 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Justin C. Walker" Cc: arch@FreeBSD.ORG Subject: Re: Ethernet packet padding: How much is legal? References: <732CD7A3-BEAC-11D6-92CC-000393575CAC@mac.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "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 (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