Herbert Xu wrote: > On Mon, Dec 03, 2007 at 07:14:26PM -0500, Hideo AOKI wrote: >> Let me try to use sk_forward_alloc at first, while percpu storage >> is an interesting idea. > > Actually I don't think sk_forward_alloc would work for UDP because > it runs lockless (unlike TCP which is run under a the socket lock). > > So it's either going to be the atomic op or per-cpu counters. For > me the atomic op isn't the issue, it's the SMP cache-line bouncing > that's more important so having something that did atomic ops on a > socket counter which then feeds into the global counter would solve > my concerns. > > But let's wait and see what Dave has to say about this too.
Hello, I suppose that he also wants to have per-socket accounting to avoid global counter access. To achieve this, I think I have three ideas at present. I'd appreciate if you let me know acceptable idea or any suggestions. 1. Using sk_forward_alloc and adding socket lock UDP already uses a socket lock to send message. However, it doesn't use the lock to receive message. I wonder if we can also use the lock when sk_forward_alloc is updated in receive processing. I understand performance issue might occur, but ... 2. Adding new atomic_t variable for memory accounting Datagram protocols will use the variable for per-socket memory accounting. Stream protocols continue to use sk_forward_alloc. 3. Replacing current sk_forward_alloc with union type Stream protocols use the union as int, and datagram protocols use it as atomic_t. Best regards, Hideo -- Hitachi Computer Products (America) Inc. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
