All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.r.fastabend@intel.com>
To: Jarek Poplawski <jarkao2@gmail.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"hadi@cyberus.ca" <hadi@cyberus.ca>,
	"shemminger@vyatta.com" <shemminger@vyatta.com>,
	"tgraf@infradead.org" <tgraf@infradead.org>,
	"eric.dumazet@gmail.com" <eric.dumazet@gmail.com>,
	"bhutchings@solarflare.com" <bhutchings@solarflare.com>,
	"nhorman@tuxdriver.com" <nhorman@tuxdriver.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [net-next-2.6 PATCH v5 2/2] net_sched: implement a root container qdisc sch_mqprio
Date: Wed, 05 Jan 2011 18:31:09 -0800	[thread overview]
Message-ID: <4D25296D.8070902@intel.com> (raw)
In-Reply-To: <20110106003208.GA2166@del.dom.local>

On 1/5/2011 4:32 PM, Jarek Poplawski wrote:
> On Wed, Jan 05, 2011 at 09:38:44AM -0800, John Fastabend wrote:
>> On 1/4/2011 2:59 PM, Jarek Poplawski wrote:
>>> On Tue, Jan 04, 2011 at 10:56:46AM -0800, John Fastabend wrote:
> ...
>>>> +
>>>> +     /* Always use supplied priority mappings */
>>>> +     for (i = 0; i < TC_BITMASK + 1; i++) {
>>>> +             if (netdev_set_prio_tc_map(dev, i, qopt->prio_tc_map[i])) {
>>>> +                     err = -EINVAL;
>>>
>>> This would probably trigger if we try qopt->num_tc == 0. Is it expected?
>>
>> netdev_set_prio_tc_map() returns 0 on sucess. This if(..) is a bit strange though.
>>
>>         err = netdev_set_prio_tc_map(dev, i, qopt->prio_tc_map[i])
>>         if (err)
>>                 ...
>>
>> Is cleaner IMHO.
> 
> Maybe. But I still wonder if qopt->num_tc == 0 is valid (by design)?
> (netdev_set_prio_tc_map() returns -EINVAL if dev->num_tc == 0)
> 

I guess I don't see how it returns -EINVAL. Although setting
qopt->num_tc = 0 is equivalent to disabling traffic classes so
it is a strange thing to do but I don't expect it should be a
problem.

static inline
int netdev_set_prio_tc_map(struct net_device *dev, u8 prio, u8 tc)
{
        if (tc >= dev->num_tc)
                return -EINVAL;

        dev->prio_tc_map[prio & TC_BITMASK] = tc & TC_BITMASK;
        return 0;
}

>>>> +static unsigned long mqprio_get(struct Qdisc *sch, u32 classid)
>>>> +{
>>>> +     unsigned int ntx = TC_H_MIN(classid);
>>>
>>> We need to 'get' tc classes too, eg for individual dumps. Then we
>>> should omit them in .leaf, .graft etc.
>>>
>>
>> OK missed this. Looks like iproute2 always sets NLM_F_DUMP which works because it uses cl_ops->walk
>>
>> # tc -s class show dev eth3 classid 800b:1
>> class mqprio 800b:1 root
>>  Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>  backlog 0b 0p requeues 0
> 
> OK, then it might be only of theoretical value (for some other tools).
>>> Why dev->num_tc above, netdev_get_num_tc(dev) here, and dev->num_tc
>>> below?
>>
>> No reason just inconsistant I will use dev->num_tc.
> 
> Well, this would suggest netdev_get_num_tc() is redundant.
> 

Guess it is I can remove it.

static inline
u8 netdev_get_num_tc(const struct net_device *dev)
{
        return dev->num_tc;
}

>>>> +static void mqprio_walk(struct Qdisc *sch, struct qdisc_walker *arg)
>>>> +{
>>>> +     struct net_device *dev = qdisc_dev(sch);
>>>> +     unsigned long ntx;
>>>> +     u8 num_tc = netdev_get_num_tc(dev);
>>>> +
>>>> +     if (arg->stop)
>>>> +             return;
>>>> +
>>>> +     /* Walk hierarchy with a virtual class per tc */
>>>> +     arg->count = arg->skip;
>>>> +     for (ntx = arg->skip; ntx < dev->num_tx_queues + num_tc; ntx++) {
>>>
>>> Should we report possibly unused/unconfigured tx_queues?
>>
>> I think it may be OK select_queue() could push skbs onto these queues and we may still want to see the statistics in this case. Although (real_num_tx_queues + num_tc) may make sense I see no reason to show queues above real_num_tx_queues.
> 
> IMHO, pushing skbs to unconfigured/unwanted/disabled queues is a bug,
> and select should handle this, but probably it's a matter of taste.

certainly a bug for queues >= real_num_tx_queues.

> Btw, I wonder how dev->real_num_tx_queues is obeyed here.
> 

Its not. real_num_tx_queues is not handled correctly here also
real_num_tx_queues can be changed so this need to be handled as well.
This means an additional check in the options parsing.

> Thanks,
> Jarek P.
> 
> PS: No offense, but could you try cutting lines ~70c. It's strongly
> recommended on kernel lists.

None taken ~70c from now on.

  reply	other threads:[~2011-01-06  2:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-04 18:56 [net-next-2.6 PATCH v5 1/2] net: implement mechanism for HW based QOS John Fastabend
2011-01-04 18:56 ` [net-next-2.6 PATCH v5 2/2] net_sched: implement a root container qdisc sch_mqprio John Fastabend
2011-01-04 22:59   ` Jarek Poplawski
2011-01-05 17:38     ` John Fastabend
2011-01-05 17:47       ` Stephen Hemminger
2011-01-06  0:32       ` Jarek Poplawski
2011-01-06  2:31         ` John Fastabend [this message]
2011-01-06 15:41           ` Jarek Poplawski
2011-01-06 18:20 ` [net-next-2.6 PATCH v5 1/2] net: implement mechanism for HW based QOS Ben Hutchings
2011-01-06 18:31   ` Eric Dumazet
2011-01-06 18:45     ` John Fastabend
2011-01-06 18:56       ` Eric Dumazet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D25296D.8070902@intel.com \
    --to=john.r.fastabend@intel.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=hadi@cyberus.ca \
    --cc=jarkao2@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=shemminger@vyatta.com \
    --cc=tgraf@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.