grep -rwn MAX_TCP_HEADER /usr/src/linux | grep define
Regards
Mohanlal
regards,
parag
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
hi,
yes i got it but still i am not getting correct value of MAX_TCP_HEADER.
what i got in tcp.h is
#define MAX_TCP_HEADER (128 + MAX_HEADER)
then the question is MAX__HEADER value? i also got it in include/linux/netdevice.h
that #define MAX_HEADER (LL_MAX_HEADER + 48)
i am using i386 platform. using ETHERNET protocol and ipv4 packet format. can you please tell me what is then value of final MAX_HEADER.
i think it should be 32 as i am not using any AX25.
regrads,
parag.
void foo(void) {
int mysterious_value = MAX_TCP_HEADER;
}
</codesnippet>
Then, say
$ gcc -I/usr/src/linux/include -D__KERNEL__ -E snippet.c | grep -w mysterious_value
The output is what you're looking for.
HTH
Michael
hi,
thanks for your reply. as you said i did the same. and got follwing output.
int mysterious_value = (128 + (96 + 48));
so what i get answer is 272 is that right.
regards,
parag.
On Mon, 10 May 2004 Michael Svetlik wrote :
>On Monday 10 May 2004 10:14, bunty wrote:
> > i am not getting correct value of MAX_TCP_HEADER.
> > what i got in tcp.h is
> > #define MAX_TCP_HEADER (128 + MAX_HEADER)
>
>Paste the following code snippet into some file, say 'snippet.c':
><codesnippet>
>#include <net/tcp.h>
>
>void foo(void) {
> int mysterious_value = MAX_TCP_HEADER;
>}
></codesnippet>
>
>Then, say
>$ gcc -I/usr/src/linux/include -D__KERNEL__ -E snippet.c | grep -w mysterious_value
>
>The output is what you're looking for.
>
>HTH
>Michael
>
Why do you need the exact value, whats wrong with using the defines?
>
> regrads,
> parag.
>
>
>
>
> _ [_ h_ t_ t_ p_ :_ /_ /_ a_ d_ s_ ._ r_ e_ d_ i_ f_ f_ ._ c_ o_ m_ /_ R_ e_ a_ l_ M_ e_ d_ i_ a_ /_ a_ d_ s_ /_ a_ d_ s_ t_ r_ e_ a_ m_ __ n_ x_ ._ c_ g_ i_ /_ w_ w_ w_ ._ r_ e_ d_ i_ f_ f_ m_ a_ i_ l_ ._ c_ o_ m_ /
> _ i_ n_ b_ o_ x_ ._ h_ t_ m_ @_ B_ o_ t_ t_ o_ m_ ]
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
using grep under include:
include/net/tcp.h:264:#define MAX_TCP_HEADER (128 + MAX_HEADER)
include/linux/netdevice.h:82:
#if !defined(CONFIG_AX25) && !defined(CONFIG_AX25_MODULE) && !defined(CONFIG_TR)
#define LL_MAX_HEADER 32
#else
#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
#define LL_MAX_HEADER 96
#else
#define LL_MAX_HEADER 48
#endif
#endif
#if !defined(CONFIG_NET_IPIP) && \
!defined(CONFIG_IPV6) && !defined(CONFIG_IPV6_MODULE)
#define MAX_HEADER LL_MAX_HEADER
#else
#define MAX_HEADER (LL_MAX_HEADER + 48)
#endif
> regards,
> parag
hi Micha,
>Why do you need the exact value, whats wrong with using the defines?
i want that value for the same reason i place the another question about alloc_skb to know what kernel takes tcp header value which is 20 bytes header+ options bytes.
as i told in another postings that i want to change the value of kernel space allocates to packet.
one more thing i want to know why kernel takes 272 greater value as compared to only simple TCp header+ options value.
regards,
parag.
>Kernelnewbies: Help each other learn about the Linux kernel.
>Archive: http://mail.nl.linux.org/kernelnewbies/
>FAQ: http://kernelnewbies.org/faq/
>
I don't know the exact extras it uses, but in allocation you want to
allocate the maximum memory you will need in this case so you won't
need to reallocate if more memory is needed.
Not all the buffer is sent over the line, just the part that is
actually used.
>
> regards,
> parag.
>
>
> >Kernelnewbies: Help each other learn about the Linux kernel.
> >Archive: http://mail.nl.linux.org/kernelnewbies/
> >FAQ: http://kernelnewbies.org/faq/
> >
>
>
> _ [_ h_ t_ t_ p_ :_ /_ /_ a_ d_ s_ ._ r_ e_ d_ i_ f_ f_ ._ c_ o_ m_ /_ R_ e_ a_ l_ M_ e_ d_ i_ a_ /_ a_ d_ s_ /_ a_ d_ s_ t_ r_ e_ a_ m_ __ n_ x_ ._ c_ g_ i_ /_ w_ w_ w_ ._ r_ e_ d_ i_ f_ f_ m_ a_ i_ l_ ._ c_ o_ m_ /
> _ i_ n_ b_ o_ x_ ._ h_ t_ m_ @_ B_ o_ t_ t_ o_ m_ ]
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
--
Yes, since it doesn't know at allocation time how much space will
actually be taken by the headers of each protocol, only the limits,
since the header sizes for most protocols is variable width.
In order to allocate exact sizes it would require two passes, first to
calculate the header sizes and then to actually allocate the space, and
that is more expensive then over allocation (since the kernel
over-allocates anyway - read on for that - and if you are careful it
won't matter)
Note that the kernel over-allocates anyway for sizes less then 128K due
to memory management issues, so considering the normal setting for the
MTU (1500) and since all the header overhead is less then 548 Byte you
are getting an allocation of 2048 Bytes anyway. You should be careful
in that respect with how much extra space you are allocating because if
you pass the 2048 mark you will get an allocation of 4092. Its a little
tight but possible.
If you want to see more, for skb look at alloc_skb in net/core/skbuff.c.
The skb itself is allocated of a pool of preallocated skbuffs (they are
sitting on the slabs in skbuff_head_cache, look in /proc/slabinfo, first
column is the used slabs, second is the allocated slabs and third is
slabsize, don't remember the rest of the columns).
The line allocating the skbuff (Head: i.e structure):
skb = kmem_cache_alloc(skbuff_head_cache, gfp_mask & ~__GFP_DMA);
The data is then allocated off the caches (not cached memory, under 128K
its the slabs IIRC) using kmalloc, which lives in mm/slab.c. Available
size are:
static cache_sizes_t cache_sizes[] = {
#if PAGE_SIZE == 4096
{ 32, NULL, NULL},
#endif
{ 64, NULL, NULL},
{ 128, NULL, NULL},
{ 256, NULL, NULL},
{ 512, NULL, NULL},
{ 1024, NULL, NULL},
{ 2048, NULL, NULL},
{ 4096, NULL, NULL},
{ 8192, NULL, NULL},
{ 16384, NULL, NULL},
{ 32768, NULL, NULL},
{ 65536, NULL, NULL},
{131072, NULL, NULL},
{ 0, NULL, NULL}
};
Allocating sizes smaller the 131072 gives you continuous memory IIRC,
more then that and you get non-continuous memory (the fall-back of 0 at
the end).
I'm not sure about the exact finer details since when I worked on this
it was with a system without virtual memory and about 3 years ago so
things were a little different but not too much)
> regards,
> parag.