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:   Tue, 25 May 2021 15:58:19 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Joakim Zhang <qiangqing.zhang@....com>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "frieder.schrempf@...tron.de" <frieder.schrempf@...tron.de>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: Re: [RFC net-next 2/2] net: fec: add ndo_select_queue to fix TX
 bandwidth fluctuations

> > On Sun, May 23, 2021 at 06:20:19PM +0800, Joakim Zhang wrote:
> > > From: Fugang Duan <fugang.duan@....com>
> > >
> > > As we know that AVB is enabled by default, and the ENET IP design is
> > > queue 0 for best effort, queue 1&2 for AVB Class A&B. Bandwidth of
> > > queue 1&2 set in driver is 50%, TX bandwidth fluctuated when selecting
> > > tx queues randomly with FEC_QUIRK_HAS_AVB quirk available.
> > 
> > How is the driver currently scheduling between these queues? Given the
> > 802.1q priorities, i think we want queue 2 with the highest priority for
> > scheduling. Then queue 0 and lastly queue 1.
> 
> I think currently there is no schedule between these queues in the driver.

So queues 1 and 2 are limited to 50% the total bandwidth, but are
otherwise not prioritised over queue 0? That sounds odd.

> Could you please point me where I can find mapping between priorities and queues? You prefer to below mapping?
> static const u16 fec_enet_vlan_pri_to_queue[8] = {1, 1, 0, 0, 0, 2, 2, 2};

https://en.wikipedia.org/wiki/IEEE_P802.1p

I'm not sure i actually believe the hardware does not prioritise the
queues. It seems to me, it is more likely to take frames from queues 1
and 2 if they have not consumed their 50% share.

PCP value 0 is best effort. That should really be given the same
priority as a packet without a VLAN header. Which is why i suggested
putting those packets into queue 0.

Also, if the hardware is performing prioritisation, PCP value 1,
background, when put into queue 1 will end up as higher priority then
best effort?

     Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ