netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Changli Gao <xiaosuo@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Stephen Hemminger <shemminger@vyatta.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Tom Herbert <therbert@google.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] ifb: add multi-queue support
Date: Thu, 12 Nov 2009 16:10:27 +0100	[thread overview]
Message-ID: <4AFC2563.1020902@trash.net> (raw)
In-Reply-To: <412e6f7f0911111912q27f2b0aate56c637349292c3f@mail.gmail.com>

Changli Gao wrote:
> On Wed, Nov 11, 2009 at 11:59 PM, Patrick McHardy <kaber@trash.net> wrote:
>>> +static int numtxqs = 1;
>>> +module_param(numtxqs, int, 0444);
>>> +MODULE_PARM_DESC(numtxqs, "Number of TX queues per ifb");
>> unsigned?
> 
> Yea, unsigned is better, and I need to check whether its value is
> smaller than 1 somewhere. The same will be done with IFLA_NTXQ.

Good point.

>>> +                     rcu_read_lock();
>>> +                     skb->dev = dev_get_by_index_rcu(&init_net, skb->iif);
>>> +                     if (!skb->dev) {
>>> +                             rcu_read_unlock();
>>> +                             dev_kfree_skb(skb);
>>> +                             txq->tx_dropped++;
>>> +                             break;
>>> +                     }
>>> +                     rcu_read_unlock();
>>> +                     skb->iif = dev->ifindex;
>> What protects the device from disappearing here and below during
>> dev_queue_xmit() and netif_rx_ni()?
> 
> For dev_queue_xmit(), dev is holded by skb->_dst, so there is no
> problem. But for netif_rx_ni(), I don't know how to prevent the device
> disappearing, and it seems that all the NIC drivers have this problem.
> Maybe there was the assumption about the execution context of
> netif_rx() before. Now softirq can't be executed by softirqd, so the
> packet receiving path maybe interleaved. I don't know how to prevent
> it happening.

You can either take a reference of move the rcu_read_unlock()
after the skb submission.

>>> +             break;
>>> +     case __constant_htons(ETH_P_IPV6):
>>> +             ip_proto = ipv6_hdr(skb)->nexthdr;
>>> +             addr1 = ipv6_hdr(skb)->saddr.s6_addr32[3];
>>> +             addr2 = ipv6_hdr(skb)->daddr.s6_addr32[3];
>>> +             ihl = 10;
>> Where does 10 come from?
> 
> It should be 40, after reviewing IPV6, I found that I need to loop
> until finding the right protocol value.

There is a helper for this (ipv6_skip_exthdr).

>>> +static int ifb_get_tx_queues(struct net *net, struct nlattr *tb[],
>>> +                          unsigned int *num_tx_queues,
>>> +                          unsigned int *real_num_tx_queues)
>>> +{
>>> +     if (tb[IFLA_NTXQ]) {
>>> +             *num_tx_queues = nla_get_u16(tb[IFLA_NTXQ]);
>> We currently use unsigned ints for the queue number, so please
>> use an u32 for the attribute as well.
>>
>>> +             *real_num_tx_queues = *num_tx_queues;
>>> +     } else {
>>> +             *num_tx_queues = numtxqs;
>>> +             *real_num_tx_queues = numtxqs;
>>> +     }
>>> +
>>> +     return 0;
>>> +}
>>> +
>         u16                     (*ndo_select_queue)(struct net_device *dev,
>                                                     struct sk_buff *skb);
> use u16 as the return value so ..., and I think u16 is big enough. If
> you insist on this, I'll use u32 instead.

Well, get_tx_queues() uses unsigned int, as does struct net_device.
I agree that it probably won't ever be needed, but there's no harm
in using the correct type, the attribute encoding doesn't even need
more room.

  parent reply	other threads:[~2009-11-12 15:07 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-11  9:51 [PATCH] ifb: add multi-queue support Changli Gao
2009-11-11  9:56 ` Changli Gao
2009-11-11 10:30 ` Eric Dumazet
2009-11-11 10:57   ` Changli Gao
2009-11-11 15:59 ` Patrick McHardy
2009-11-12  3:12   ` Changli Gao
2009-11-12  8:52     ` Jarek Poplawski
2009-11-12  9:32       ` Changli Gao
2009-11-12 15:10     ` Patrick McHardy [this message]
2009-11-13  1:28       ` Changli Gao
2009-11-12  9:44 ` Changli Gao
2009-11-12  9:48   ` Changli Gao
2009-11-12 15:11     ` Patrick McHardy
2009-11-13  1:32       ` Changli Gao
2009-11-13  7:18         ` Patrick McHardy
2009-11-12 12:48   ` Eric Dumazet
2009-11-13  1:26     ` Changli Gao
2009-11-13  5:56       ` Eric Dumazet
2009-11-13  6:16         ` Changli Gao
2009-11-13  7:45           ` Jarek Poplawski
2009-11-13  8:54             ` Changli Gao
2009-11-13  9:18               ` Jarek Poplawski
2009-11-13  9:38                 ` Changli Gao
2009-11-13  9:57                   ` Jarek Poplawski
2009-11-13 11:25                     ` Changli Gao
2009-11-13 12:32                       ` Jarek Poplawski
2009-11-13 13:10                       ` Eric Dumazet
2009-11-13 16:15                   ` Stephen Hemminger
2009-11-13 23:28                     ` Changli Gao
2009-11-13 23:32                       ` Stephen Hemminger
2009-11-13 23:42                         ` Changli Gao
2009-11-14 12:53                           ` Eric Dumazet
2009-11-14 13:30                             ` Changli Gao
2009-11-13 13:55               ` Eric Dumazet
2009-11-13  4:37   ` Changli Gao
2009-11-16 16:39     ` Stephen Hemminger
2009-11-17  3:10       ` David Miller
2009-11-17  5:38         ` Changli Gao
2009-11-17  6:02           ` Stephen Hemminger
  -- strict thread matches above, loose matches on Subject: below --
2009-11-16  7:31 Changli Gao
2009-11-16  8:19 ` Eric Dumazet
2009-11-16  8:43   ` Changli Gao
2009-11-13  4:42 Changli Gao
2009-11-13  4:46 ` Changli Gao
2009-11-10  8:30 Changli Gao
2009-11-10  9:07 ` Eric Dumazet
2009-11-10  9:43   ` Changli Gao
2009-11-10 10:57     ` Eric Dumazet
2009-11-10 11:14       ` Changli Gao
2009-11-10 11:41         ` Patrick McHardy
2009-11-10 12:14           ` Changli Gao
2009-11-10 12:19             ` Patrick McHardy
2009-11-10 12:37               ` Changli Gao
2009-11-10 12:45                 ` Patrick McHardy
2009-11-10 13:06                   ` Changli Gao
2009-11-10 13:34                     ` Eric Dumazet
2009-11-10 13:49                       ` Changli Gao
2009-11-10 16:45                         ` Stephen Hemminger
2009-11-11  6:30                           ` Changli Gao
2009-11-10 10:29 ` Patrick McHardy
2009-11-10 10:48   ` Changli Gao
2009-11-10 10:55     ` 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=4AFC2563.1020902@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    --cc=therbert@google.com \
    --cc=xiaosuo@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).