From owner-freebsd-arch Mon Sep 2 12:15:55 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 1E51A37B40A for ; Mon, 2 Sep 2002 12:15:46 -0700 (PDT) Received: from patrocles.silby.com (d76.as29.nwbl0.wi.voyager.net [169.207.73.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id D771843E4A for ; Mon, 2 Sep 2002 12:15:42 -0700 (PDT) (envelope-from silby@silby.com) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.6/8.12.5) with ESMTP id g82JJ4xP000363 for ; Mon, 2 Sep 2002 14:19:04 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.6/8.12.6/Submit) with ESMTP id g82JJ3gu000360 for ; Mon, 2 Sep 2002 14:19:04 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 2 Sep 2002 14:19:03 -0500 (CDT) From: Mike Silbersack To: arch@freebsd.org Subject: Ethernet packet padding: How much is legal? Message-ID: <20020902140522.W281-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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. Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message