netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Herbert <therbert@google.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: rps: some comments
Date: Thu, 7 Jan 2010 16:07:35 -0800	[thread overview]
Message-ID: <65634d661001071607k63c33a0q4f402942d64ea77e@mail.gmail.com> (raw)
In-Reply-To: <4B461D11.6050603@gmail.com>

On Thu, Jan 7, 2010 at 9:42 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Hi Tom
>
> 1) netif_receive_skb() might enqueue skb instead of handling them directly.
>
> int netif_receive_skb(struct sk_buff *skb)
> {
>        int cpu = get_rps_cpu(skb->dev, skb);
>
>        if (cpu < 0)
>                return __netif_receive_skb(skb);
>        else
>                return enqueue_to_backlog(skb, cpu);
> }
>
> If get_rps_cpu() happens to select the current cpu, we enqueue to backlog the
> skb instead of directly calling __netif_receive_skb().
>
> One way to solve this is to make get_rps_cpu() returns -1 in this case :
>
> ...
> if (cpu == smp_processor_id() || !cpu_online(cpu))
>        cpu = -1;
>
> done:
>        rcu_read_unlock();
>        return cpu;
> } /* get_rps_cpu() */
>
I kind of like the way it is right now, which is to enqueue even on
the local CPU.  The advantage of that is that all the packets received
in the napi run are dispatched to all the participating CPUs before
any are processed, this is good for average and worst case latency on
a packet burst.

>
> 2) RPS_MAP_SIZE might be too expensive to use in fast path, on big (NR_CPUS=4096) machines :
>  num_possible_cpus() has to count all bits set in a bitmap.
>
> #define MAX_RPS_CPUS (num_possible_cpus() < 256 ? num_possible_cpus() : 256)
> #define RPS_MAP_SIZE (sizeof(struct rps_map) + (MAX_RPS_CPUS * sizeof(u16))
>
> You can use nr_cpu_ids, or even better a new variable, that you init _once_ to
>
> unsigned int rps_map_size = sizeof(struct rps_map) + (min(256, nr_cpu_ids) * sizeof(u16));
>
Yes that's probably better.

>
> 3) cpu hotplug.
>
> I cannot find how cpu unplug can be safe.
>
> if (!cpu_online(cpu))
>        cpu = -1;
> rcu_read_unlock();
> ...
> cpu_set(cpu, __get_cpu_var(rps_remote_softirq_cpus));
> ...
> __smp_call_function_single(cpu, &queue->csd, 0);

I believe were dealing with remote CPUs with preemption disabled (from
softirq's), so maybe that is sufficient to prevent CPU from going away
below us.  We probably need a "if cpu_online(cpu)" before
__smp_call_function_single though.

Thanks,
Tom

  reply	other threads:[~2010-01-08  0:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-20 23:28 [PATCH v4 1/1] rps: core implementation Tom Herbert
2009-11-20 23:39 ` David Miller
2009-11-20 23:50   ` Tom Herbert
2009-11-21  0:05     ` David Miller
2009-11-21  0:12       ` Tom Herbert
2009-11-21  0:40         ` Jarek Poplawski
2009-11-20 23:40 ` Stephen Hemminger
2009-11-20 23:53   ` Tom Herbert
2009-11-20 23:56   ` David Miller
2009-12-17 21:04   ` Tom Herbert
2010-01-06  1:32     ` Tom Herbert
2010-01-06  5:54       ` Eric Dumazet
2010-01-06  7:56         ` Tom Herbert
2010-01-06 18:38         ` Eric Dumazet
2010-01-06 21:10           ` [BUG net-next-2.6] Had to revert bonding: allow arp_ip_targets on separate vlans to use arp validation Eric Dumazet
2010-01-06 21:28             ` Jay Vosburgh
2010-01-06 21:34               ` Eric Dumazet
2010-01-06 21:38             ` David Miller
2010-01-06 21:45               ` Andy Gospodarek
2010-01-06 22:56             ` [PATCH net-next-2.6] fix " Andy Gospodarek
2010-01-06 23:53               ` Jay Vosburgh
2010-01-07  8:37                 ` Eric Dumazet
2010-01-07  8:41                   ` David Miller
2010-01-06 22:54           ` [PATCH v4 1/1] rps: core implementation Tom Herbert
2010-01-07  9:15             ` Eric Dumazet
2010-01-07 17:42               ` rps: some comments Eric Dumazet
2010-01-08  0:07                 ` Tom Herbert [this message]
2010-01-08  6:27                   ` Eric Dumazet
2010-01-11  6:25               ` [PATCH v4 1/1] rps: core implementation Tom Herbert
2010-01-11  9:00                 ` Eric Dumazet
2010-01-14  4:40                   ` David Miller
2009-11-20 23:42 ` Stephen Hemminger
2009-11-21  0:04   ` Tom Herbert
2009-11-21  8:07 ` Eric Dumazet
2009-11-21  9:03   ` Tom Herbert
2009-11-21  9:31     ` 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=65634d661001071607k63c33a0q4f402942d64ea77e@mail.gmail.com \
    --to=therbert@google.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=netdev@vger.kernel.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 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).