Date: Mon, 30 Jun 2008 19:16:29 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Stefan Lambrev <stefan.lambrev@moneybookers.com> Cc: freebsd-net@freebsd.org Subject: Re: if_bridge turns off checksum offload of members? Message-ID: <20080630101629.GD79537@cdnetworks.co.kr> In-Reply-To: <4868A34C.6030304@moneybookers.com> References: <4868A34C.6030304@moneybookers.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 30, 2008 at 12:11:40PM +0300, Stefan Lambrev wrote: > Greetings, > > I just noticed, that when I add em network card to bridge the checksum > offload is turned off. > I even put in my rc.conf: > ifconfig_em0="rxcsum up" > ifconfig_em1="rxcsum up" > but after reboot both em0 and em1 have this feature disabled. > > Is this expected behavior? Should I care about csum in bridge mode? > I noticed that enabling checksum offload manually improve things little btw. > AFAIK this is intended one, bridge(4) turns off Tx side checksum offload by default. I think disabling Tx checksum offload is required as not all members of a bridge may be able to do checksum offload. The same is true for TSO but it seems that bridge(4) doesn't disable it. If all members of bridge have the same hardware capability I think bridge(4) may not need to disable Tx side hardware assistance. I guess bridge(4) can scan every interface capabilities in a member and can decide what hardware assistance can be activated instead of blindly turning off Tx side hardware assistance. > Also I'm experimenting with bridge performance and with today's 7-stable > I can't reach > the results from my previous test with 7-current (before few months) > > The best that bridge can do today is just 720kpps (just incoming) vs > 1000kpps with sources from few months ago. > I'm using the same hardware and same configuration so I'm not sure why > -stable is slower. > > -- > > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080630101629.GD79537>