| 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
| ||
|
Message-ID: <nn1v69qsjd.fsf@stalhein.lysator.liu.se> Date: Thu, 25 Nov 2010 17:25:42 +0100 From: nisse@...ator.liu.se (Niels Möller) To: Eric Dumazet <eric.dumazet@...il.com> Cc: linux-kernel@...r.kernel.org, netdev <netdev@...r.kernel.org> Subject: Re: TCP_MAXSEG vs TCP/generic segmentation offload (tso/gso) Eric Dumazet <eric.dumazet@...il.com> writes: > I believe TCP_MAXSEG is working fine, but GRO/GSO dont care at all : > They coalesce frames whatever their size is. I was under the impression that TSO (and maybe GSO) implied more cleverness in the network card; that the network card more or less gets to decide by itself how to divide a tcp stream into segments. And for example in the atl1c driver which I looked a bit into, this was what the REG_MTU register was for. Seems I have gotten this totally wrong. Maybe Documentation/networking/netdevices.txt could clarify how it works. Currently, it says : Segmentation Offload (GSO, TSO) is an exception to this rule. The : upper layer protocol may pass a large socket buffer to the device : transmit routine, and the device will break that up into separate : packets based on the current MTU. Regards, and thanks for your patience, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. -- 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
Powered by blists - more mailing lists