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:   Wed, 6 Jan 2021 12:56:08 +0100
From:   Marek Behún <kabel@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Sven Auhagen <sven.auhagen@...eatech.de>, netdev@...r.kernel.org,
        davem@...emloft.net, Jakub Kicinski <kuba@...nel.org>,
        Matteo Croce <mcroce@...rosoft.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>
Subject: Re: [PATCH net-next] net: mvpp2: increase MTU limit when XDP
 enabled

On Tue, 5 Jan 2021 21:21:10 +0100
Andrew Lunn <andrew@...n.ch> wrote:

> On Tue, Jan 05, 2021 at 06:43:08PM +0100, Marek Behún wrote:
> > On Tue, 5 Jan 2021 18:24:37 +0100
> > Sven Auhagen <sven.auhagen@...eatech.de> wrote:
> >   
> > > On Tue, Jan 05, 2021 at 06:19:21PM +0100, Marek Behún wrote:  
> > > > Currently mvpp2_xdp_setup won't allow attaching XDP program if
> > > >   mtu > ETH_DATA_LEN (1500).
> > > > 
> > > > The mvpp2_change_mtu on the other hand checks whether
> > > >   MVPP2_RX_PKT_SIZE(mtu) > MVPP2_BM_LONG_PKT_SIZE.
> > > > 
> > > > These two checks are semantically different.
> > > > 
> > > > Moreover this limit can be increased to MVPP2_MAX_RX_BUF_SIZE, since in
> > > > mvpp2_rx we have
> > > >   xdp.data = data + MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM;
> > > >   xdp.frame_sz = PAGE_SIZE;
> > > > 
> > > > Change the checks to check whether
> > > >   mtu > MVPP2_MAX_RX_BUF_SIZE    
> > > 
> > > Hello Marek,
> > > 
> > > in general, XDP is based on the model, that packets are not bigger than 1500.
> > > I am not sure if that has changed, I don't believe Jumbo Frames are upstreamed yet.
> > > You are correct that the MVPP2 driver can handle bigger packets without a problem but
> > > if you do XDP redirect that won't work with other drivers and your packets will disappear.  
> > 
> > At least 1508 is required when I want to use XDP with a Marvell DSA
> > switch: the DSA header is 4 or 8 bytes long there.
> > 
> > The DSA driver increases MTU on CPU switch interface by this length
> > (on my switches to 1504).
> > 
> > So without this I cannot use XDP with mvpp2 with a Marvell switch with
> > default settings, which I think is not OK.  
> 
> Hi Marek
> 
> You are running XDP programs on the master interface? So you still
> have the DSA tag? What sort of programs are you running? I guess DOS
> protection could work, once the program understands the DSA tag. To
> forward the frame out another interface you would have to remove the
> tag. Or i suppose you could modify the tag and send it back to the
> switch? Does XDP support that sort of hairpin operation?
> 
> 	Andrew

Andrew,

I am using bpf_fib_lookup to route the packets between switch
interfaces.
Here's the program for Marvell CN9130 CRB
https://blackhole.sk/~kabel/src/xdp_mvswitch_route.c
(This is just to experiment with XDP, so please excuse code quality.)

I found out that on Turris MOX I am able to route 2.5gbps (at MTU 1500)
with XDP. But when not using XDP, when the packets go via kernel's
stack, MOX is able to route less than 1gbps (cca 800mbps, at MTU
1500, and the CPU is at 100%).

I also to write a simple NAT masquerading program. I think XDP can
increase NAT throughput to 2.5gbps as well.

> Or i suppose you could modify the tag and send it back to the
> switch? Does XDP support that sort of hairpin operation?

You can modify the packet, prepend it with another headers (up to 256
bytes in some drivers, in mvpp2 only 224), append trailers... Look at
my program above, I am popping vlan tag, for example.

Marek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ