Resending as gmail borked the message somehow and it didn't made it to
netdev.
On 7/8/05, David S. Miller <[EMAIL PROTECTED]> wrote:
> That's why I'm working on shrinking the size assuming all the
> config options are enabled, because that is the reality for most
> installations.
> For all of this stuff we could consider stealing some ideas from BSD,
> namely doing something similar to their MBUF tags.
> If a subsystem wants to add a cookie to a networking buffer, it
> allocates a tag and links it into the struct.
Humm...
<brainstorm>
what about having a skb_extensions_size global variable that initially is
set to sizeof(struct skb_shared_info), but as subsystems are initialized
they bump skb_extensions_size using skb_alloc_extension(size_t bytes), that
returns the offset after skb->end?
Using skb_shared_info as an example:
skb_shared_info_offset = skb_alloc_extension(sizeof(struct
skb_shared_info));
that as the first call to skb_alloc_extension() would of course return 0
and skb_extensions_size would become:
skb_extensions_size += sizeof(struct skb_shared_info);
in alloc_skb we would have:
size = SKB_DATA_ALIGN(size);
data = kmalloc(size + skb_extensions_size, gfp_mask);
#define skb_shinfo(SKB) ((struct skb_shared_info *)((SKB)->end))
Would become:
#define skb_shinfo(SKB) ((struct skb_shared_info *)((SKB)->end + \
skb_shared_info_offset))
The skb_shared_info case would be optimized as we know
skb_shared_info_offset is always 0, but the other subsystems would pay this
add price, but we would have just one kmalloc.
Of course only the skbs created after the skb_alloc_extension() call would
be valid for the subsystem that allocated the extension, would this be a
problem?
</brainstorm>
Flaws? :-)
- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
