netdev - Re: [PATCH net-next] myri10ge: add adaptive coalescing

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] [day] [month] [year] [list]

Message-Id: <20091006.222521.167077213.davem@davemloft.net>
Date:	Tue, 06 Oct 2009 22:25:21 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	Brice.Goglin@...-lyon.org, bgoglin@...e.fr
Cc:	rick.jones2@...com, brice@...i.com, netdev@...r.kernel.org,
	gallatin@...i.com
Subject: Re: [PATCH net-next] myri10ge: add adaptive coalescing

From: Brice Goglin <bgoglin@...e.fr>
Date: Wed, 07 Oct 2009 07:17:46 +0200

> Rick Jones wrote:
>> David Miller wrote:
>>> From: Brice Goglin <brice@...i.com>
>>> Date: Tue, 06 Oct 2009 18:52:43 +0200
>>>
>>>
>>>> This patch adds support for adaptive interrupt coalescing to the
>>>> myri10ge driver. It is based on the host periodically look at
>>>> statistics and update the NIC coalescing accordingly.
>>>>
>>>> The NIC only provides packet throughput and we feel that it is a
>>>> better heuristics than the packet rate heuristics currently used
>>>> in ethtool. Also, assuming that the packet packet rate heuristics
>>>> uses what is actually sent on the wire when using TSO, it would be
>>>> much more expensive to implement correctly, as the driver would
>>>> need to calculate how many packets were sent.
>>>>
>>>> Signed-off-by: Andrew Gallatin <gallatin@...i.com>
>>>> Signed-off-by: Brice Goglin <brice@...i.com>
>>>
>>>
>>> Drivers tried to do this as far back as 6 years ago (tg3) and we don't
>>> recommend doing this with NAPI drivers.
>>
>> Doesn't e1000(e) still try to do adaptive coalescing?
> 
> mlx_en, benet, sfc, ... do as well.

If the patches that added that code slipped by me, my bad.  But
if I had noticed I would have been against them as well.

It really isn't the right thing to do.  By the same arguments
it is even arguable to turn off TCP congestion control completely
on local subnets.

It is absolutely impossible to react to on-the-wire changes in
traffic patterns at the granularity in which we get to execute.
It simply is not possible to do it right.
--
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