Re: [RFC net-next] net/sched: act_mirred: allow mirred ingress through networking backlog

[Cong Wang <xiyou.wangcong@gmail.com>]

On Mon, Oct 31, 2022 at 10:44:26PM +0100, Davide Caratti wrote:
> using TC mirrred in the ingress direction, packets are passed directly
> to the receiver in the same context. There are a couple of reasons that
> justify the proposal to use kernel networking backlog instead:
> 
> a) avoid the soft lockup observed with TCP when it sends data+ack after
>    receiving packets through mirred (William sees them using OVS,
>    something similar can be obtained with a kselftest [1)]

Do you have a pointer to the original bug report? The test case you
crafted looks unreal to me, a TCP socket sending packets to itself does
not look real.


> b) avoid packet drops caused by mirred hitting MIRRED_RECURSION_LIMIT
>    in the above scenario
> 
> however, like Cong pointed out [2], we can't just change mirred redirect to
> use the networking backlog: this would break users expectation, because it
> would be impossible to know the RX status after a packet has been enqueued
> to the backlog.
> 
> A possible approach can be to extend the current set of TC mirred "eaction",
> so that the application can choose to use the backlog instead of the classic
> ingress redirect. This would also ease future decisions of performing a
> complete scrub of the skb metadata for those packets, without changing the
> behavior of existing TC ingress redirect rules.
> 

From users' point of view, why do we need to care about this
implemention detail when picking TC mirred action?


Thanks.