netdev - Re: LRO restructuring?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Aug 2008 17:54:34 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.apana.org.au
Cc:	gallatin@...i.com, netdev@...r.kernel.org, brice@...i.com
Subject: Re: LRO restructuring?

From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Tue, 12 Aug 2008 08:50:33 +0800

> On Mon, Aug 11, 2008 at 09:30:33AM -0400, Andrew Gallatin wrote:
> >
> > For lro_receive_frags() based LRO, it would be ideal to locate the
> > header in place in the frag via the mac_hdr argument to the
> > get_frag_header() callback.  Eg, I'm hoping that neither the driver
> > nor the LRO module will need to allocate extra memory per frame and
> > copy the headers to it in the common case when forwarding is
> > not enabled.  That would add quite a bit of overhead.
> 
> You don't have to save the whole thing, just save enough so we
> can easily/exactly reconstruct it on output, i.e., save the lengths.

And the checksums :-)  As an intermediate node we don't want
to touch the checksum.

The length and the checksum is two u16 values, which would be
able to fit in a single 32-bit descriptor or something like
that.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html