On Fri, Sep 01, 2017 at 11:27:43AM -0700, Florian Fainelli wrote: > On 09/01/2017 10:55 AM, Andrew Lunn wrote: > > Hi Florian > > > >>>> 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