From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6345 invoked from network); 8 Dec 2022 01:43:40 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 8 Dec 2022 01:43:40 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 9front; Wed Dec 7 20:42:03 -0500 2022 Message-ID: <5F8CD36108E8E2775841BE403EB18383@felloff.net> Date: Thu, 08 Dec 2022 02:41:53 +0100 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: flexible persistence ActivityPub over AJAX pipelining-oriented engine-aware locator Subject: Re: [9front] [patch] ethervgbe: add rx checksum offloading Reply-To: 9front@9front.org Precedence: bulk sorry, but yes. we have a fast-path where we skip checking the ip header cheksum if the Block has the flag that says it was already checked by hardware: if((bp->flag & Bipck) == 0 && ipcsum(&h->vihl)) { ip->stats[InHdrErrors]++; netlog(f, Logip, "%V -> %V: bad ip header checksum\n", h->src, h->dst); goto drop; } i cannot say if this is really worth it tho. i have no measured it. and the ip *HEADER* is not very big and the code in ipcsum() has a fast-path in itself handling the common fixed header size case. i would say the complexity of this is very low. all the ethernet driver needs todo is set a flag on the Block to say hw already calculated the ip header checksum. also, we do not memcpy every packet. thats what Block's and Block lists are about. the ip fragments are stored as lists of packets (with all the headers) without touching them until it becomes really neccessary. the Block's are directly filled by hardware dma in the common ethernet case. maybe you ment when the payload gets passed to userspace? in that case, yes, when data is tranferred between userspace and kernel memory it gets copied. but within the kernel, qio/blocks are avoiding doing that. -- cinap