RE: [RFC net-next 2/2] net: fec: add ndo_select_queue to fix TX bandwidth fluctuations

[Joakim Zhang]

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: 2021年5月25日 21:58
> To: Joakim Zhang <qiangqing.zhang@xxxxxxx>
> Cc: davem@xxxxxxxxxxxxx; kuba@xxxxxxxxxx; frieder.schrempf@xxxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; dl-linux-imx
> <linux-imx@xxxxxxx>
> 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@xxxxxxx>
> > > >
> > > > 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.
No, when enable AVB (configured as Credit-based scheme), queue 0 is best effort, queue 1 is limited to 50% bandwidth, queue 2 is also limited to 50% bandwidth.
I may misunderstand to you, what I mean is that there is no scheduler from software level, Net core calls netdev_pick_tx() to select a queue. From the hardware level, schedule with Credit-based.

> > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikip
> edia.org%2Fwiki%2FIEEE_P802.1p&amp;data=04%7C01%7Cqiangqing.zhang%
> 40nxp.com%7C30d975f09a79446030d608d91f852c39%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C637575479097053920%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C1000&amp;sdata=g6WxJJVXLbaX3QWBq3yB4fk1Zh4tN%2Ff8Y
> w%2FAATabL%2Bg%3D&amp;reserved=0
Err, this link isn't available at my side. It's seems 802.1q spec.

> 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.
Hardware xmits with Credit-based scheme.

> 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.
Make sense.

> 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?
I don't think so, Credit-based scheduler would schedule based on credit, not the PCP filed.

Best Regards,
Joakim Zhang
> 
>      Andrew