David Miller wrote:
> From: Hideo AOKI <[EMAIL PROTECTED]>
> Date: Thu, 15 Nov 2007 16:50:14 -0500
>
>> +static inline int __ip_check_max_skb_pages(struct sock *sk, int size)
>> +{
>> + switch(sk->sk_protocol) {
>> + case IPPROTO_UDP:
>> + if (atomic_read(sk->sk_prot->memory_allocated) + size
>> + > sk->sk_prot->sysctl_mem[0])
>> + return -ENOBUFS;
>> + /* Fall through */
>> + default:
>> + break;
>> + }
>> + return 0;
>> +}
>> +
<snip>
>
> These special case checks are all over the place.
>
> We don't have tests all over the place to see if a socket is TCP or
> DCCP or SCTP in order to implement memory accounting there, because we
> did it for connection oriented protocols cleanly, seperating things
> via callbacks etc.
>
> I would like to see the datagram memory accounting work similarly.
Hello,
I'm still thinking this and focusing on enhancement of above function.
However, I feel difficulty because socket buffer allocation of UDP
sending packet is in IP layer: ip_append_data(). Moreover, the function
is called from several protocols including TCP. This makes setting
callback hard without changing function interface or core data structure.
Then, I would like to know if the following implementation could be
acceptable.
- Adding sk_datagram_{rw}mem_schedule() as a memory schedule function
for datagram protocols.
- Adding sk_wmem_schedule().
In the function, sk_stream_wmem_schedule() is called if the caller
socket is stream protocols. Moreover, sk_datagram_wmem_schedule()
is called if the socket is datagram like this:
int sk_wmem_schedule(struct sock *sk, int size)
{
...
switch (sk->sk_type) {
case SOCK_STREAM:
return sk_stream_wmem_schedule(sk, size);
case SOCK_DGRAM:
return sk_datagram_wmem_schedule(sk, size);
default:
return 1;
}
}
- In ip_append_data(), sk_wmem_schedule() is called to execute
memory accounting.
Please let me know if you have any comments about this.
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
