netdev - Re: [RFC PATCH net-next 0/7] NIC driver Rx ring ECN

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]

Message-ID: <ee84e51b-e41d-9613-fac7-42fa58a1f7ac@redhat.com>
Date:   Thu, 19 Jan 2023 17:05:55 +0000
From:   Jeremy Harris <jeharris@...hat.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, jgh@...hat.com
Subject: Re: [RFC PATCH net-next 0/7] NIC driver Rx ring ECN



On 13/01/2023 00:09, Jakub Kicinski wrote:
> It may be cool if we can retrofit some second-order signal into
> the time-based machinery. The problem is that we don't actually
> have any time-based machinery upstream, yet :(
> And designing interfaces for a decade-old HW seems shortsighted.
> 
>>> Host level congestion is better detected using time / latency signals.
>>> Timestamp the packet at the NIC and compare the Rx time to current time
>>> when processing by the driver.
>>>
>>> Google search "Google Swift congestion control".

> Grep for HWTSTAMP_FILTER_ALL, there's HW out there.

OK.

>> - does not address Rx drops due to Rx ring-buffer overflow
> 
> It's a stronger signal than "continuous run of packets".
> You can have a standing queue of 2 packets, and keep processing
> for ever. There's no congestion, or overload. You'd see that
> timestamps are recent.

Agreed.  That's why marking at a proportion of ring-fill approaching
100% was my "preferred" implementation.  But if the current situation
with NIC API design makes that commonly impractical, I guess it's
a dead duck.

> I experimented last year with implementing CoDel on the input queues,
> worked pretty well (scroll down ~half way):
> 
> https://developers.facebook.com/blog/post/2022/04/25/investigating-tcp-self-throttling-triggered-overload/

That looks nice.  Are there any plans to get that upstream?
-- 
Cheers,
   Jeremy