netdev - Re: [PATCH net-next v3 1/4] net: dsa: add support for DSA rx offloading via metadata dst

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:   Mon, 14 Nov 2022 13:06:42 +0100
From:   Felix Fietkau <nbd@....name>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3 1/4] net: dsa: add support for DSA rx
 offloading via metadata dst

On 14.11.22 12:55, Vladimir Oltean wrote:
> On Sat, Nov 12, 2022 at 12:13:15PM +0100, Felix Fietkau wrote:
>> On 12.11.22 05:40, Jakub Kicinski wrote:
>> I don't really see a valid use case in running generic XDP, TC and NFT on a
>> DSA master dealing with packets before the tag receive function has been
>> run. And after the tag has been processed, the metadata DST is cleared from
>> the skb.
> 
> Oh, there are potentially many use cases, the problem is that maybe
> there aren't as many actual implementations as ideas? At least XDP is,
> I think, expected to be able to deal with DSA tags if run on a DSA
> master (not sure how that applies when RX DSA tag is offloaded, but
> whatever). Marek Behun had a prototype with Marvell tags, not sure how
> far that went in the end:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg381018.html
> In general, forwarding a packet to another switch port belonging to the
> same master via XDP_TX should be relatively efficient.
In that case it likely makes sense to disable DSA tag offloading 
whenever driver XDP is being used.
Generic XDP probably doesn't matter much. Last time I tried to use it 
and ran into performance issues, I was told that it's only usable for 
testing anyway and there was no interest in fixing the cases that I ran 
into.

>> How about this: I send a v4 which uses skb_dst_drop instead of skb_dst_set,
>> so that other drivers can use refcounting if it makes sense for them. For
>> mtk_eth_soc, I prefer to leave out refcounting for performance reasons.
>> Is that acceptable to you guys?
> 
> I don't think you can mix refcounting at consumer side with no-refcounting
> at producer side, no?
skb_dst_drop checks if refcounting was used for the skb dst pointer.

> I suppose that we could leave refcounting out for now, and bug you if
> someone comes with a real need later and complains. Right now it's a bit
> hard for me to imagine all the possibilities. How does that sound?
Sounds good. I think I'll send v4 anyway to deal with the XDP case and 
to switch to skb_dst_drop.

- Felix