Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*I\s+need\s+sk_buff\s+frag_list\s+info\.\s*$/: 22 ]

Total 22 documents matching your query.

1. I need sk_buff frag_list info. (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Fri, 15 Mar 2002 14:15:22 -0500
I am working on a change to the IBM 405 Ethernet driver. The Ethernet allows us to define buffer sizes smaller than the MTU size. If a packet comes in larger than the buffer size, it will be received
/archives/netdev/2002-03/msg00090.html (8,870 bytes)

2. Re: I need sk_buff frag_list info. (score: 1)
Author: wiz@xxxxxxxxxx>
Date: Sat, 16 Mar 2002 01:37:12 +0100
What is an IBM 405? Only when you don't want to support TCP. TCP will always reallocate and copy list linked packets currently. frag_list is purely a hack to handle fragmented packets for UDP and RAW
/archives/netdev/2002-03/msg00091.html (9,716 bytes)

3. Re: I need sk_buff frag_list info. (score: 1)
Author: en <ak@xxxxxxx>
Date: Fri, 15 Mar 2002 16:47:21 -0800
An embedded PPC chip, with the ethernet built into the chip. Well I still have not seen any ethernet card do this. Even though it seems that the hardware would support it. This could be a big help fo
/archives/netdev/2002-03/msg00092.html (9,676 bytes)

4. Re: I need sk_buff frag_list info. (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Sat, 16 Mar 2002 01:54:34 +0100
The headers should be in skb->data if possible. If not the stack will do some copying. So you could put some arbitary first fragment (e.g. 128 bytes) there. -Andi
/archives/netdev/2002-03/msg00093.html (9,251 bytes)

5. Re: I need sk_buff frag_list info. (score: 1)
Author: e@xxxxxxxxxxxx>
Date: Fri, 15 Mar 2002 22:43:12 -0500 (EST)
Presumably you are trying to receive into smaller chunks in an effort to save memory. If so, your goal is misguided. A significant part of the work in receiving packets is handling the skbuffer alloc
/archives/netdev/2002-03/msg00096.html (11,034 bytes)

6. Re: I need sk_buff frag_list info. (score: 1)
Author: cker@xxxxxxxxx>
Date: Sun, 17 Mar 2002 10:59:28 +0100
The current skbuff allocator uses kmalloc for the data part. kmalloc currently always rounds to a power of two. So for any you will get a 2K buffer. The skbuff head recycling works independently of t
/archives/netdev/2002-03/msg00097.html (9,382 bytes)

7. Re: I need sk_buff frag_list info. (score: 1)
Author: anton@xxxxxxxx>
Date: Mon, 18 Mar 2002 07:34:39 -0500
I'll try to be a little more clear on what I need to do. The hardware has a size limit to a single buffer of 4K. It also has a receive buffer size register. If I wanted to receive a 9K packet, JUMBO,
/archives/netdev/2002-03/msg00099.html (10,521 bytes)

8. Re: I need sk_buff frag_list info. (score: 1)
Author: wiz@xxxxxxxxxx>
Date: Mon, 18 Mar 2002 13:45:49 +0100
In 2.4 it doesn't anymore, but only some networking protocols support it (TCP/UDP/RAW). The others just always fallback to copying if they cannot deal with a multi paged skb. This should work with a
/archives/netdev/2002-03/msg00100.html (10,818 bytes)

9. Re: I need sk_buff frag_list info. (score: 1)
Author: n@xxxxxxxxxxxx>
Date: Mon, 18 Mar 2002 12:39:37 -0500 (EST)
I sure Andi noticed the wording, but for others that didn't: I wrote: "the opportunity", which the current implementation doesn't take advantage of. There have been prototype allocator implementation
/archives/netdev/2002-03/msg00104.html (10,986 bytes)

10. Re: I need sk_buff frag_list info. (score: 1)
Author: cker@xxxxxxxxx>
Date: Thu, 21 Mar 2002 17:42:19 +0100
I fully agree. I played with this a few years ago with slab (you can still see the commented out skb_add_mtu() function in skbuff.c), but it didn't help much with 4K pages. Now with 8K page sizes bec
/archives/netdev/2002-03/msg00105.html (9,930 bytes)

11. Re: I need sk_buff frag_list info. (score: 1)
Author: en <ak@xxxxxxx>
Date: Fri, 22 Mar 2002 13:41:09 +0100
Hello! Here is an related experiment with e1000 allocating different slab-sizes Originally e1000 allocates 4k slabs for ordinary 1500 MTU ethernet packets. The e1000 driver was changed to use 2k as a
/archives/netdev/2002-03/msg00112.html (10,319 bytes)

12. I need sk_buff frag_list info. (score: 1)
Author: "Mark Wisner" <markwiz@xxxxxxxxxx>
Date: Fri, 15 Mar 2002 14:15:22 -0500
I am working on a change to the IBM 405 Ethernet driver. The Ethernet allows us to define buffer sizes smaller than the MTU size. If a packet comes in larger than the buffer size, it will be received
/archives/netdev/2002-03/msg00233.html (8,870 bytes)

13. Re: I need sk_buff frag_list info. (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Sat, 16 Mar 2002 01:37:12 +0100
What is an IBM 405? Only when you don't want to support TCP. TCP will always reallocate and copy list linked packets currently. frag_list is purely a hack to handle fragmented packets for UDP and RAW
/archives/netdev/2002-03/msg00234.html (9,810 bytes)

14. Re: I need sk_buff frag_list info. (score: 1)
Author: andrew may <acmay@xxxxxxxxxxxxxxxx>
Date: Fri, 15 Mar 2002 16:47:21 -0800
An embedded PPC chip, with the ethernet built into the chip. Well I still have not seen any ethernet card do this. Even though it seems that the hardware would support it. This could be a big help fo
/archives/netdev/2002-03/msg00235.html (9,781 bytes)

15. Re: I need sk_buff frag_list info. (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Sat, 16 Mar 2002 01:54:34 +0100
The headers should be in skb->data if possible. If not the stack will do some copying. So you could put some arbitary first fragment (e.g. 128 bytes) there. -Andi
/archives/netdev/2002-03/msg00236.html (9,383 bytes)

16. Re: I need sk_buff frag_list info. (score: 1)
Author: Donald Becker <becker@xxxxxxxxx>
Date: Fri, 15 Mar 2002 22:43:12 -0500 (EST)
Presumably you are trying to receive into smaller chunks in an effort to save memory. If so, your goal is misguided. A significant part of the work in receiving packets is handling the skbuffer alloc
/archives/netdev/2002-03/msg00239.html (11,096 bytes)

17. Re: I need sk_buff frag_list info. (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Sun, 17 Mar 2002 10:59:28 +0100
The current skbuff allocator uses kmalloc for the data part. kmalloc currently always rounds to a power of two. So for any you will get a 2K buffer. The skbuff head recycling works independently of t
/archives/netdev/2002-03/msg00240.html (9,523 bytes)

18. Re: I need sk_buff frag_list info. (score: 1)
Author: "Mark Wisner" <markwiz@xxxxxxxxxx>
Date: Mon, 18 Mar 2002 07:34:39 -0500
I'll try to be a little more clear on what I need to do. The hardware has a size limit to a single buffer of 4K. It also has a receive buffer size register. If I wanted to receive a 9K packet, JUMBO,
/archives/netdev/2002-03/msg00242.html (10,521 bytes)

19. Re: I need sk_buff frag_list info. (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Mon, 18 Mar 2002 13:45:49 +0100
In 2.4 it doesn't anymore, but only some networking protocols support it (TCP/UDP/RAW). The others just always fallback to copying if they cannot deal with a multi paged skb. This should work with a
/archives/netdev/2002-03/msg00243.html (10,912 bytes)

20. Re: I need sk_buff frag_list info. (score: 1)
Author: Donald Becker <becker@xxxxxxxxx>
Date: Mon, 18 Mar 2002 12:39:37 -0500 (EST)
I sure Andi noticed the wording, but for others that didn't: I wrote: "the opportunity", which the current implementation doesn't take advantage of. There have been prototype allocator implementation
/archives/netdev/2002-03/msg00247.html (11,030 bytes)


This search system is powered by Namazu