[openbeos] Re: Some network land questions:

Hi Oliver,

better late than never, they say :-)

"Oliver Ruiz Dorantes" <urnenfel@xxxxxxxxxx> wrote:
> Going further with the desgin, headers placement, and first coding.
> I saw a "int32 type" not used in the net_buffer context, can be 
> confirmed?

With the exception of "size" you can use all other fields of the public 
net_buffer structure as you like (outside of the networking stack, that 
is).

> Is there any way i can "ensure" the net_buffer is contiguous? like 
> creating
> it with the exact amount of data it is gonna hold... and only 
> "appening"

Nope, the buffer is currently always 2K in size, most of that is 
available to you, but you can't make it larger (if you don't change the 
source).

> data? As consequence question what is the first parameter of the 
> create
> function granting?

"header space" - that means you can prepend that many bytes (only if it 
would fit inside the default buffer size, of course) to the buffer 
without having to split it internally. It's just to speed up working 
with the buffers, so that it never needs to split with the standard 
ethernet packet processing.

> If there is no way for this... Maybe the "duplicate" function could 
> be
> useful to create another net_buffer that grants to be contiguous? 
> (passing a
> extra bool for that?)

The net_buffer uses the slab allocator directly (for its fixed size 
buffers), so that's not really an option.
Why would you need it to be contiguous so desperately?

> In the worst case that we need to allocate a secondary buffer to dump 
> all
> the data, I would suggest to add another field, a pointer field, (as 
> linux
> sk_buff has) in the net_buffer structure.
> So that we dont need to create extra structures to know where is that
> buffer that I allocated to have this
> net_buffer contiguous... so i can free it just before i free the 
> net_buffer
> 
> In all cases, I think this generic pointer would be usefull for many 
> other
> things, generally as a cookie.... (which dev is handling, etc 
> etc...).
> Assuming we would not like to cast the (uint32 flags) to (void*)...

You can add a pointer type to the union if you need that. Besides this, 
I am not sure I understand what you're getting at with this.

> PD:
> is there gonna be some documentation about the network Stack after 
> GSoC?

It obviously did not pop up from nowhere, but some day...

Bye,
   Axel.

Other related posts: