From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bin Ren Subject: Re: [PATCH] Network Checksum Removal Date: Mon, 23 May 2005 17:06:07 +0100 Message-ID: <8ae7802505052309067d88f174@mail.gmail.com> References: <20050520233015.GA26305@us.ibm.com> <200505231029.14649.habanero@us.ibm.com> <8ae7802505052308313bcc4b56@mail.gmail.com> <200505231047.10709.habanero@us.ibm.com> <8ae78025050523085662a94019@mail.gmail.com> Reply-To: bin.ren@cl.cam.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <8ae78025050523085662a94019@mail.gmail.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Theurer Cc: Xen-devel@lists.xensource.com, Jon Mason List-Id: xen-devel@lists.xenproject.org Start from fresh again. The same weird symptoms. - Bin On 5/23/05, Bin Ren wrote: > I'm using bridge and stock scripts. I start to doubt it's caused csum > offloading, as I'm seeing some weird things. (1) it's possible to do > interdomain iperf, which binds to ports > 1024 (2) ssh and nfs don't > work. In both cases, dom0 is the server, dom1 is the client. tcpdump > on dom0 doesn't show any incoming packets from dom1. >=20 > I'm recompiling everything again. >=20 > Cheers, > Bin >=20 > On 5/23/05, Andrew Theurer wrote: > > On Monday 23 May 2005 10:31, Bin Ren wrote: > > > It seems to break the interdomain ssh and nfs on my machine. Digging > > > for reasons. > > > > Are you using bridge or network model? > > > > > > - Bin > > > > > > On 5/23/05, Andrew Theurer wrote: > > > > > I've checked in a modified version of your patch that hopefully > > > > > deals with propagating checksum information in both directions > > > > > across a virtual bridge or router. I replaced your skb flags with > > > > > two new ones -- proto_csum_blank and proto_csum_valid. > > > > > > > > > > The former indicates that the protocol-level checksum needs > > > > > filling in. This is not a problem for local processing, but the > > > > > flag is picked up before sending to a physical interface and > > > > > fixed up. > > > > > > > > > > The latter indicates that the proto-level checksum has been > > > > > validated since arrival at localhost (*or* that the packet > > > > > originated from a domU on localhost). This flag survives crossing > > > > > a bridge/router so we can trust it when deciding if checksum > > > > > validation is required. > > > > > > > > > > I'll push the patch to the bkbits repository just as soon as > > > > > bkbits rematerialises. :-) > > > > > > > > > > If you have any performance or stress tests that you were using > > > > > to test checksum offloading, it would be great to find out how > > > > > they perform on the checked-in version! > > > > > > > > Now that BK is up, I'll run some netperf tests before/after that > > > > changeset and see what we get. > > > > > > > > -Andrew > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@lists.xensource.com > > > > http://lists.xensource.com/xen-devel > > > > >