netdev - Re: Generic TSO

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:	Fri, 11 Mar 2016 15:22:26 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	ecree@...arflare.com
Cc:	tom@...bertland.com, netdev@...r.kernel.org
Subject: Re: Generic TSO

From: Edward Cree <ecree@...arflare.com>
Date: Fri, 11 Mar 2016 19:20:41 +0000

> Are you planning to / working on implementing this?  If not, I might have a
> crack at it; I've talked to our firmware guys and (provisionally) we think
> we can support it in current sfc hardware.
> Or were there any blocking problems raised in the thread?  My understanding
> of the IP ID issue was that it only matters for the inner frame, because
> the rest aren't TCP (so hopefully no-one is doing SLHC on them).  But I may
> have missed something.

I've thought a lot more about the IP ID issue, and I am now starting
to learn towards allowing it to be set to zero for "DF" packets.

Considering what we gain in return, not working optimally with an
ancient SLIP header compression implementation is a small loss.

Any other opinions?