From owner-freebsd-sparc64@FreeBSD.ORG Tue Apr 19 04:50:16 2005 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D872C16A4CE for ; Tue, 19 Apr 2005 04:50:16 +0000 (GMT) Received: from rndsoft.co.kr (michelle.rndsoft.co.kr [211.32.202.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF7B043D3F for ; Tue, 19 Apr 2005 04:50:15 +0000 (GMT) (envelope-from yongari@rndsoft.co.kr) Received: from yongari@rndsoft.co.kr(192.168.5.90) by MailFilter v1.05 with ESMTP Processed in 0.127586 secs; 19 Apr 2005 13:48:30 +0900 Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.1/8.13.1) with ESMTP id j3J4nlBi005808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2005 13:49:47 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.1/8.13.1/Submit) id j3J4nkVY005807; Tue, 19 Apr 2005 13:49:46 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Date: Tue, 19 Apr 2005 13:49:46 +0900 From: Pyun YongHyeon To: John-Mark Gurney Message-ID: <20050419044946.GB4941@michelle.rndsoft.co.kr> References: <20050414092608.GB2855@michelle.rndsoft.co.kr> <20050414192749.GO56487@funkthat.com> <20050415023902.GC7393@michelle.rndsoft.co.kr> <20050415030935.GQ56487@funkthat.com> <20050415042731.GD7393@michelle.rndsoft.co.kr> <20050415051112.GE7393@michelle.rndsoft.co.kr> <20050415154309.GS56487@funkthat.com> <20050416004627.GA11603@michelle.rndsoft.co.kr> <20050416170133.GA16099@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050416170133.GA16099@funkthat.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-sparc64@freebsd.org Subject: Re: em(4) patch X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: yongari@rndsoft.co.kr List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2005 04:50:17 -0000 On Sat, Apr 16, 2005 at 10:01:33AM -0700, John-Mark Gurney wrote: > Pyun YongHyeon wrote this message on Sat, Apr 16, 2005 at 09:46 +0900: > > On Fri, Apr 15, 2005 at 08:43:09AM -0700, John-Mark Gurney wrote: > > > Sten Spans wrote this message on Fri, Apr 15, 2005 at 12:09 +0200: > > > > >With your changes JUMBO frames work here. This should also fix PR75794. > > > > >It would be really great if your changes could be comitted. > > > > > > > > Let's not forget ipv6 please, it needs this fix too, > > > > if the code is imported. > > > > > > And netatalk, netipsec and netipx too will probably need these changes.. > > > > > > Another reason I haven't brought in the code quite yet... > > > > Hmm, this means we have to patch all filrewalls(pf/ipfw/ipf), carp(4) > > and possibily netgraph(4) too. I'm afraid this is not right direction > > to go. Alignment fixup would be best served in ether_input or in driver > > layer which seems to be more appropriate place. Maybe this is the > > reason why OpenBSD have such a complex alignment code in em driver. > > Please make sure you know the entire problem before you say it's no > the correct way to go... Drivers like re and vge have to copy up an > entire cluster (2k), just to make alignment correct... It's even more > ugly than patching everyone to self align... > > Also, IMO, it's the correct layer to put the fix up in each firewalls, > etc.. Because the driver should not magicly know that the upper layers > need an alignment.. Plus, what happens if someone happens to use foobar > which only needs 2 byte alignment... Why should we continue to fixup > packets on alignment constrained machines when this layer doesn't need > it? > Personally, I beleive all upper layers(> L2) assume its payload is aligned correctly(maybe NFS is exception). So if lower layers give no assurance on alignment it have to check whether it needs alignment fixup(currently no such check exist and your m_copyup would handle this transparently). According to my experimentation your m_copyup works well. But this means all protocol handlers should have this check too and I think that is hard to maintain since there are so many places to add this code. AFAIK all firewalls can be run under bridge environments. In this situation they need your alignment fixup code too. However if lower layer(ethernet layer or driver layer) can provide alignment free mbuf, there is no need to add a such alignment fixup code. In addition, I believe we can avoid alignment fixup code for architecures that allow non-aligned memory access in driver layer by defining conditioanal compilation. Of course, driver layer does not know that upper layers need an alignment. However I think almost all protocols have designed to align 4 byte boundary so ethernet header and its type field would be the only exception. If a protocol handler need x byte alignment it should handle this in its protocol handler since other parts of code assumes 4 byte boundary, IMO. > Hence why I am trying to get some performance measurements to see just > the performance difference the extra mbuf allocation makes over coping > data... -- Regards, Pyun YongHyeon http://www.kr.freebsd.org/~yongari | yongari@freebsd.org