netdev - Re: using software TSO on non-TSO capable netdevices

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:	Wed, 30 Jul 2008 16:56:21 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	buytenh@...tstofly.org
Cc:	netdev@...r.kernel.org, akarkare@...vell.com, nico@....org
Subject: Re: using software TSO on non-TSO capable netdevices

From: Lennert Buytenhek <buytenh@...tstofly.org>
Date: Thu, 31 Jul 2008 01:50:04 +0200

Thanks for all the great data and testing.

> Given this, I'm wondering about the following:
> 
> 1. Considering the drop in CPU utilisation, are there reasons not
>    to use software GSO on non-hardware-GSO-capable netdevices (apart
>    from GSO possibly confusing tcpdump/iptables/qdiscs/etc)?

We should probably enable software GSO whenever the device can
do scatter-gather and checksum offload.

> 2. Why is the number of cycles necessary to send 1 GiB of data so
>    much higher (~3.5x higher) in 1000 Mb/s mode than in 100 Mb/s mode?
>    (Is this maybe just because time(1) is inaccurate w.r.t. time spent
>    in interrupts and such?)

This I have no idea about.

> 3. Why does dev_hard_start_xmit() get sent 64 KiB segments when the
>    link is in 100 Mb/s mode but gso_segs never grows beyond 3 when
>    the link is in 1000 Mb/s mode?

Because the link can empty the socket send buffer fast enough such
that there is often not enough data to coalesce into larger GSO frames.
At least that's my guess.
--
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