Hello, Thank you so much for your comments.
David Miller wrote: > All of these other functions are identical copies of the stream > counterparts, they should all be consolidated. > > I still see a lot of special casing, instead of large pieces of common > code. > > There should be one core set of functions that handle the memory > accounting, regardless of socket type. Maybe there is one spot where > something like sk->prot->doing_memory_accounting is tested, but that's > it. I understood. I'll re-write my patch set to make memory accounting core functions. > Also, the memory accounting is done at different parts in > the socket code paths for stream vs. datagram. This is why > everything is inconsistent, and, a mess. Could you tell me more detailed information? Does this comment mean interface and usage of memory accounting functions? If so, I'll consolidate functions like sk_stream_set_owner_r() and sk_stream_free_skb(). And, I may have to use memory accounting functions in memory allocating functions like sk_stream_alloc_pskb() as possible instead of inside of socket operating functions. Or, does the comment mean that send buffer accounting in IP layer (e.g. ip_append_data()) is wrong? Anyway, in next patch set, I'm going to consolidate mem_schedule functions and mem_reclaim functions. To do so, some of memory accounting functions for stream protocols will be renamed or be moved to core/sock.c from core/stream.c. I would like to know what kind of enhancement must be needed for memory accounting core functions. Again, thank you for taking your time to review this feature. 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
