From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jarek Poplawski <jarkao2@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Tom Herbert <therbert@google.com>,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next-2.6] net: Xmit Packet Steering (XPS)
Date: Fri, 20 Nov 2009 15:45:42 +0100 [thread overview]
Message-ID: <4B06AB96.8040805@gmail.com> (raw)
In-Reply-To: <20091120133245.GA9038@ff.dom.local>
Jarek Poplawski a écrit :
> On 20-11-2009 00:46, Eric Dumazet wrote:
>> Here is first version of XPS.
>>
>> Goal of XPS is to free TX completed skbs by the cpu that submitted the transmit.
>
> But why?... OK, you write in another message about sock_wfree(). Then
> how about users, who don't sock_wfree (routers)? Will there be any way
> to disable it?
This is open for discussion, but I saw no problem with routing workloads.
sock_wfree() is not that expensive for tcp anyway.
You also have a cost of kfreeing() two blocks of memory per skb, if allocation was done by another cpu.
If this happens to be a problem, we can immediately free packet if it
has no destructors :
At xmit time, initialize skb->sending_cpu like that
skb->sending_cpu = (skb->destructor) ? smp_processor_id() : 0xFFFF;
to make sure we dont touch too many cache lines at tx completion time.
>> +/*
>> + * XPS : Xmit Packet Steering
>> + *
>> + * TX completion packet freeing is performed on cpu that sent packet.
>> + */
>> +#if defined(CONFIG_SMP)
>
> Shouldn't it be in the Makefile?
It is in Makefile too, I let it in prelim code to make it clear this was CONFIG_SMP only.
>
> ...
>> +/*
>> + * called at end of net_rx_action()
>> + * preemption (and cpu migration/offline/online) disabled
>> + */
>> +void xps_flush(void)
>> +{
>> + int cpu, prevlen;
>> + struct sk_buff_head *head = per_cpu_ptr(xps_array, smp_processor_id());
>> + struct xps_pcpu_queue *q;
>> + struct sk_buff *skb;
>> +
>> + for_each_cpu_mask_nr(cpu, __get_cpu_var(xps_cpus)) {
>> + q = &per_cpu(xps_pcpu_queue, cpu);
>> + if (cpu_online(cpu)) {
>> + spin_lock(&q->list.lock);
>
> This lock probably needs irq disabling: let's say 2 cpus run this at
> the same time and both are interrupted with these (previously
> scheduled) IPIs?
Repeat after me :
lockdep is my friend, lockdep is my friend, lockdep is my friend... :)
Seriously, I must think again on this locking schem.
>> +static void remote_free_skb_list(void *arg)
>> +{
>> + struct sk_buff *last;
>> + struct softnet_data *sd;
>> + struct xps_pcpu_queue *q = arg; /* &__get_cpu_var(xps_pcpu_queue); */
>> +
>> + spin_lock(&q->list.lock);
>> +
>> + last = q->list.prev;
>
> Is q->list handled in case this cpu goes down before this IPI is
> triggered?
[block migration] (how ? this is the question)
if (cpu_online(cpu)) {
give_work_to_cpu(cpu);
trigger IPI
} else {
handle_work_ourself()
}
[unblock migration]
General problem is : what guards cpu going off line between the if (cpu_online(cpu))
and the IPI.
I dont know yet, but it seems that disabling preemption is enough to get this
guarantee. This seems strange.
We can add a notifier (or better call a function from existing one : dev_cpu_callback()) to
flush this queue when necessary.
Thanks
next prev parent reply other threads:[~2009-11-20 14:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-19 23:46 [PATCH net-next-2.6] net: Xmit Packet Steering (XPS) Eric Dumazet
2009-11-20 2:12 ` Changli Gao
2009-11-20 4:58 ` Eric Dumazet
2009-11-20 5:11 ` Changli Gao
2009-11-20 5:24 ` Eric Dumazet
2009-11-20 5:34 ` Changli Gao
2009-11-20 5:42 ` Eric Dumazet
2009-11-20 5:50 ` Changli Gao
[not found] ` <65634d660911191641o4210a797mf1e8168dd8dd8b60@mail.gmail.com>
2009-11-20 5:08 ` Eric Dumazet
2009-11-20 13:32 ` Jarek Poplawski
2009-11-20 14:45 ` Eric Dumazet [this message]
2009-11-20 20:04 ` Jarek Poplawski
2009-11-20 21:43 ` Eric Dumazet
2009-11-20 22:08 ` Jarek Poplawski
2009-11-20 22:21 ` Eric Dumazet
2009-11-20 20:51 ` Andi Kleen
2009-11-20 20:53 ` David Miller
2009-11-20 22:30 ` Eric Dumazet
2009-11-20 22:37 ` Andi Kleen
[not found] ` <65634d660911201642k3930dc78vd576e0e89dc0c794@mail.gmail.com>
2009-11-21 6:58 ` Eric Dumazet
2009-11-20 20:53 ` Jarek Poplawski
2009-11-20 21:35 ` Eric Dumazet
2009-11-20 21:43 ` Joe Perches
2009-11-20 21:49 ` David Miller
2009-11-20 22:01 ` Eric Dumazet
2009-11-20 22:34 ` David Miller
2009-11-20 22:32 ` David Miller
2009-11-20 22:36 ` 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=4B06AB96.8040805@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=jarkao2@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=therbert@google.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 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.