* Re: Skbuff Trimming
[not found] <Pine.GSO.4.44.0206271756540.727-100000@noisy.cs.clemson.edu.suse.lists.linux.kernel>
@ 2002-06-28 3:04 ` Andi Kleen
2002-06-28 19:06 ` Bendi Vinaya Kumar
2002-06-30 2:14 ` Bendi Vinaya Kumar
0 siblings, 2 replies; 4+ messages in thread
From: Andi Kleen @ 2002-06-28 3:04 UTC (permalink / raw)
To: Bendi Vinaya Kumar; +Cc: linux-kernel
Bendi Vinaya Kumar <vbendi@cs.clemson.edu> writes:
> But, it does not do the same on
> "frag_list". Why?
frag_list is not a general purpose skbuff facility and is not used by
most protocols and not directly supported by most of skbuff.c It is just
supported by some specific paths to enable lazy defragmenting. It is not
an attempt to turn skbuffs into mbufs.
-Andi
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Skbuff Trimming
2002-06-28 3:04 ` Skbuff Trimming Andi Kleen
@ 2002-06-28 19:06 ` Bendi Vinaya Kumar
2002-06-30 2:14 ` Bendi Vinaya Kumar
1 sibling, 0 replies; 4+ messages in thread
From: Bendi Vinaya Kumar @ 2002-06-28 19:06 UTC (permalink / raw)
To: linux-kernel
On 28 Jun 2002, Andi Kleen wrote:
> Bendi Vinaya Kumar <vbendi@cs.clemson.edu> writes:
>
> > But, it does not do the same on
> > "frag_list". Why?
>
> frag_list is not a general purpose skbuff facility and is not used by
> most protocols and not directly supported by most of skbuff.c It is just
> supported by some specific paths to enable lazy defragmenting. It is not
> an attempt to turn skbuffs into mbufs.
>
> -Andi
I agree with you. I couldn't find a
case when it (frag_list) is used.
Function
ip_rcv
(http://lxr.linux.no/source/net/ipv4/ip_input.c#L383)
uses two functions, namely,
1) pskb_may_pull, which might
result in a call to __pskb_pull_tail
and 2) __pskb_trim, which might
result in a call to ___pskb_trim.
Function __pskb_pull_tail
operates on data in both frags
array and frag_list. As mentioned
earlier, ___pskb_trim doesn't operate
on frag_list. Since these two functions
are called from ip_rcv, they must be
operating on the same sk buff. One function
handles frag_list, the other doesn't.
Isn't there an inconsistency in treatment here,
even though frag_list is not commonly used
in practice?
Thank you.
Regards,
Vinaya Kumar Bendi
P.S.: Kindly CC any answers/comments
to vbendi@cs.clemson.edu.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Skbuff Trimming
2002-06-28 3:04 ` Skbuff Trimming Andi Kleen
2002-06-28 19:06 ` Bendi Vinaya Kumar
@ 2002-06-30 2:14 ` Bendi Vinaya Kumar
1 sibling, 0 replies; 4+ messages in thread
From: Bendi Vinaya Kumar @ 2002-06-30 2:14 UTC (permalink / raw)
To: linux-kernel
June 29, 2002
Hi,
Guess, I understand now.
__pskb_pull_tail operates on
frag_list as well, since it is
required to pull a header (completely)
into kmalloc'd area pointed to by
skb->data.
It is, however, not required of
___pskb_trim. So, frag_list, in this
case, may be avoided.
Thanks.
Regards,
Vinaya Kumar Bendi
P.S.: Kindly CC any answers/comments
to vbendi@cs.clemson.edu.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Skbuff Trimming
@ 2002-06-27 22:10 Bendi Vinaya Kumar
0 siblings, 0 replies; 4+ messages in thread
From: Bendi Vinaya Kumar @ 2002-06-27 22:10 UTC (permalink / raw)
To: linux-kernel
June 27, 2002
Hi,
I have a question for anyone
who has been through the following
function,
___pskb_trim
(http://lxr.linux.no/source/net/core/skbuff.c#L739)
This function tries to trim an
skbuff off any trailing pad bytes.
It goes about doing its job, going
through "frags" array.
But, it does not do the same on
"frag_list". Why?
Thank you for your time.
Regards,
Vinaya Kumar Bendi
P.S.: Kindly CC any answers/comments
to vbendi@cs.clemson.edu.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-06-30 2:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.GSO.4.44.0206271756540.727-100000@noisy.cs.clemson.edu.suse.lists.linux.kernel>
2002-06-28 3:04 ` Skbuff Trimming Andi Kleen
2002-06-28 19:06 ` Bendi Vinaya Kumar
2002-06-30 2:14 ` Bendi Vinaya Kumar
2002-06-27 22:10 Bendi Vinaya Kumar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox