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]
Date:   Mon, 14 Nov 2022 14:33:45 +0100
From:   Felix Fietkau <nbd@....name>
To:     Dave Taht <dave.taht@...il.com>
Cc:     Vladimir Oltean <olteanv@...il.com>,
        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 14:18, Dave Taht wrote:
> On Mon, Nov 14, 2022 at 4:21 AM Felix Fietkau <nbd@....name> wrote:
>>
>> 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.
> 
> XDP continues to evolve rapidly, as do its use cases. ( ex:
> ttps://github.com/thebracket/cpumap-pping#readme )
> 
> What cases did you run into?
My issue was the fact that XDP in general (including generic XDP) 
assumes that packets have 256 bytes of headroom, which is usually only 
true for drivers that already have proper driver or hardware XDP support.
That makes generic XDP pretty much useless for normal use, since on XDP 
capable drivers you should use driver/hardware XDP anyway, and on 
everything else you get the significant performance penalty of an extra 
pskb_expand_head call.
I ended up abandoning XDP for my stuff and used tc instead.

- Felix

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ