Thread (20 messages) 20 messages, 2 authors, 2017-09-01

Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness

From: Andrew Lunn <andrew@lunn.ch>
Date: 2017-09-01 18:50:16

On Fri, Sep 01, 2017 at 11:27:43AM -0700, Florian Fainelli wrote:
On 09/01/2017 10:55 AM, Andrew Lunn wrote:
quoted
Hi Florian
quoted
quoted
quoted
tc bind dev sw0p0 queue 0 dev eth0 queue 16
It this the eth0 i don't like here. Why not in the implementation just
use something like netdev_master_upper_dev_get('sw0p0')? Or does
Last I brought this up with Jiri that we should link DSA network devices
to their master network deviecs with netdev_upper_dev_link() he said
this was not appropriate for DSA slave network devices, but I can't
remember why, I would assume that any stacked device set up would do that.
There is some form a linking going, our device names show that:

9: lan5@eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether da:87:2a:03:cf:16 brd ff:ff:ff:ff:ff:ff
In any case, we need to establish a mapping so we have to specify at
least the target device's queue number. It is quite similar in premise
to e.g: enslaving a network device to a bridge port:

ip link set dev eth0 master br0
But here br0 is absolutely required, we have to say which bridge the
slave port should be a member of.

But what good is eth0 in

tc bind dev sw0p0 queue 0 dev eth0 queue 16

As i said suggesting, you have to somehow verify that eth0 is the
conduit interface sw0p0 is using. Which makes the parameter pointless.
Determine it from the sw0p0 somehow.

	  Andrew
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help