[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090508.144859.152310605.davem@davemloft.net>
Date: Fri, 08 May 2009 14:48:59 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: dada1@...mosbay.com
Cc: khc@...waw.pl, netdev@...r.kernel.org
Subject: Re: [PATCH] net: reduce number of reference taken on sk_refcnt
From: Eric Dumazet <dada1@...mosbay.com>
Date: Fri, 08 May 2009 17:12:39 +0200
> For example, we can avoid the dst_release() cache miss if this
> is done in start_xmit(), and not later in TX completion while freeing skb.
> I tried various patches in the past but unfortunatly it seems
> only safe way to do this is in the driver xmit itself, not in core
> network stack. This would need many patches, one for each driver.
There might be a way around having to hit every driver.
The case we can't muck with is when the route will be used.
Devices which create this kind of situation can be marked with
a flag bit in struct netdevice. If that flag bit isn't set,
you can drop the DST in dev_hard_start_xmit().
> [PATCH] net: reduce number of reference taken on sk_refcnt
>
> Current sk_wmem_alloc schema uses a sk_refcnt taken for each packet
> in flight. This hurts some workloads at TX completion time, because
> sock_wfree() has three cache lines to touch at least.
> (one for sk_wmem_alloc, one for testing sk_flags, one
> to decrement sk_refcnt)
>
> We could use only one reference count, taken only when sk_wmem_alloc
> is changed from or to ZERO value (ie one reference count for any number
> of in-flight packets)
>
> Not all atomic_add() must be changed to atomic_add_return(), if we
> know current sk_wmem_alloc is already not null.
>
> This patch reduces by one number of cache lines dirtied in sock_wfree()
> and number of atomic operation in some workloads.
>
> Signed-off-by: Eric Dumazet <dada1@...mosbay.com>
I like this idea. Let me know when you have some at least
basic performance numbers and wish to submit this formally.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists