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:   Sun, 4 Mar 2018 06:56:02 +0000
From:   Stefan Chulski <stefanc@...vell.com>
To:     Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Antoine Tenart <antoine.tenart@...tlin.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "maxime.chevallier@...tlin.com" <maxime.chevallier@...tlin.com>,
        "gregory.clement@...tlin.com" <gregory.clement@...tlin.com>,
        "miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>,
        Nadav Haklai <nadavh@...vell.com>,
        Yan Markman <ymarkman@...vell.com>,
        "mw@...ihalf.com" <mw@...ihalf.com>
Subject: RE: [PATCH net-next 5/5] net: mvpp2: jumbo frames support

> >  		netdev_err(port->dev, "Invalid pool %d\n", pool);
> >  		return NULL;
> >  	}
> > @@ -4596,11 +4604,24 @@ mvpp2_bm_pool_use(struct mvpp2_port
> *port, int
> > pool, int pkt_size)  static int mvpp2_swf_bm_pool_init(struct
> > mvpp2_port *port)  {
> >  	int rxq;
> > +	enum mvpp2_bm_pool_log_num long_log_pool, short_log_pool;
> > +
> > +	/* If port pkt_size is higher than 1518B:
> > +	 * HW Long pool - SW Jumbo pool, HW Short pool - SW Short pool
> 
> The comment is wrong. In this case, the HW short pool is the SW long pool.

You right. Comment is wrong.

> > +	if (port->pool_long->id == MVPP2_BM_JUMBO && port->id != 0) {
> 
> Again, all over the place we hardcode the fact that Jumbo frames can only be
> used on port 0. I know port 0 is the only one that can do 10G, but are there
> possibly some use cases where you may want Jumbo frame on another port
> ?
> 
> This all really feels very hardcoded to me.
> 

All ports support Jumbo frames.
But only port 0 can do TX HW checksum offload(due to TX FIFO size).

Packet processor 2.2 has only 19KB TX FIFO size.
So in TX FIFO config code assign for Port 0 - 10KB, Port 1 - 3KB and Port 1 - 3KB.

To perform checksum in HW, HW obviously should work in store and forward mode. Store all frame in TX FIFO and then check checksum.
If mtu 1500B, everything fine and all port can do this.

If mtu is 9KB and 9KB frame transmitted, Port 0 still can do HW checksum. But ports 1 and 2 doesn't has enough FIFO for this.
So we cannot offload this feature and SW should perform checksum.

> > +	/* 9704 == 9728 - 20 and rounding to 8 */
> > +	dev->max_mtu = MVPP2_BM_JUMBO_PKT_SIZE;
> 
> Is this correct for all ports ? Shouldn't the maximum MTU be different
> between port 0 (that supports Jumbo frames) and the other ports ?

This is correct for all ports. All ports can support Jumbo frames.

Stefan.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ