* Query on skb buffer
@ 2013-03-06 18:39 Kumar amit mehta
2013-03-06 19:32 ` Valdis.Kletnieks at vt.edu
0 siblings, 1 reply; 2+ messages in thread
From: Kumar amit mehta @ 2013-03-06 18:39 UTC (permalink / raw)
To: kernelnewbies
My current understanding is that the skb, while being passed along various
layers in linux network stack, will be manipulated majorly, using the
skb->{head|data|tail|end|len} fields.
Suppose that my application (say 'ping') sends a ICMP echo request with a
large packet size of 4k, i.e. $ ping -s 4096 <dest addr>
Now, if alloc_skb(4096, GFP_KERNEL) is the routine that gets called to allocate
the kernel buffer then, how does the kernel manages such prospective memory
allocation failures and how kernel manages large packet requests from the
application.
-Amit
^ permalink raw reply [flat|nested] 2+ messages in thread* Query on skb buffer
2013-03-06 18:39 Query on skb buffer Kumar amit mehta
@ 2013-03-06 19:32 ` Valdis.Kletnieks at vt.edu
0 siblings, 0 replies; 2+ messages in thread
From: Valdis.Kletnieks at vt.edu @ 2013-03-06 19:32 UTC (permalink / raw)
To: kernelnewbies
On Wed, 06 Mar 2013 10:39:13 -0800, Kumar amit mehta said:
> Now, if alloc_skb(4096, GFP_KERNEL) is the routine that gets called to allocate
> the kernel buffer then, how does the kernel manages such prospective memory
> allocation failures and how kernel manages large packet requests from the
> application.
Did you actually look at the source for use of alloc_skb() and how it
handles error returns?
(Hint - the kernel doesn't do the same thing at every use of alloc_skb(),
because an allocation failure needs to be handled differently depending on
where it happens. At some places, just bailing out and dropping the packet
on the floor without any notification to anybody is appropriate. At other
places, we need to propagate an error condition to the caller).
Typical pattern (from net/core/sock.c:)
/*
* Allocate a skb from the socket's send buffer.
*/
struct sk_buff *sock_wmalloc(struct sock *sk, unsigned long size, int force,
gfp_t priority)
{
if (force || atomic_read(&sk->sk_wmem_alloc) < sk->sk_sndbuf) {
struct sk_buff *skb = alloc_skb(size, priority);
if (skb) {
skb_set_owner_w(skb, sk);
return skb;
}
}
return NULL;
}
EXPORT_SYMBOL(sock_wmalloc);
and then the caller does something like this (net/ipv4/ip_output.c,
in function __ip_append_data():
} else {
skb = NULL;
if (atomic_read(&sk->sk_wmem_alloc) <=
2 * sk->sk_sndbuf)
skb = sock_wmalloc(sk,
alloclen + hh_len + 15, 1,
sk->sk_allocation);
if (unlikely(skb == NULL))
err = -ENOBUFS;
else
/* only the initial fragment is
time stamped */
cork->tx_flags = 0;
}
if (skb == NULL)
goto error;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130306/3d3208a1/attachment.bin
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2013-03-06 19:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-06 18:39 Query on skb buffer Kumar amit mehta
2013-03-06 19:32 ` Valdis.Kletnieks at vt.edu
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.