[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170901185012.GA8122@lunn.ch>
Date: Fri, 1 Sep 2017 20:50:12 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: jiri@...nulli.us, jhs@...atatu.com, netdev@...r.kernel.org,
davem@...emloft.net, xiyou.wangcong@...il.com,
vivien.didelot@...oirfairelinux.com
Subject: Re: [RFC net-next 0/8] net: dsa: Multi-queue awareness
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@...1: <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
Powered by blists - more mailing lists