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.
next prev 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).