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

[Jeremy Harris <jeharris@redhat.com>]

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