In message <20010220110113.C3910@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> you write:
> > sorry, but this doesn't make sense to me. adding a single pointer to
> > struct sk_buff is a _way_ smaller patch to the kernel than changing
> > huge amounts of code in netfilter, iptables, iproute2 and tc.
>
> I agree it is a way smaller patch, but it is still a patch that we
> want to avoid.
>
> ...that could be useful to others who want to mark packets without
> guessing if any other netfilter module is going to inadvertantly use
> or modify it.
The classic nfmark field problem; that there is only one. See also,
nfct.
For a generic linked-list of blobs approach, there are several
problems:
1) How do I tell which one is mine?
2) What happens when packet is copied?
3) What happens when packet is cloned?
4) What happens when packet is destroyed?
For nfmark, the answers are:
2) Copy it.
3) Copy it.
4) Free it.
For nfct, the answers are:
2) Copy it, bump refcnt.
3) Copy it, bump refcnt.
4) Dec refcnt, if zero call destructor.
Some other stuff has similar properties.
struct nf_info
{
struct nf_info *next;
atomic_t refcnt;
/* Unique identifier, suggest a valid unique pointer */
void *identifier;
/* Called on skb_copy */
int (*copy)(struct skbuff *oldskb,
struct skbuff *newskb,
struct nf_info *me);
/* Called on skb_clone */
int (*clone)(struct skbuff *oldskb,
struct skbuff *newskb,
struct nf_info *me);
/* Called if atomic_dec_and_test(&refcnt) == 0 in __kfree_skb */
int (*destroy)(struct skbuff *dyingskb,
struct nf_info *me);
/* Your data goes here... */
};
static inline skb_get_nfinfo(struct sk_buff *skb, void *id)
{
struct nf_info *i;
for (i = (skb)->nf_info; i && i->identifier != id; i = i->next);
return i;
}
My gut reaction is against the heaviness of this proposal, but maybe
the networking gurus think it's worth the pain, as there *is* other
cruft in the skb which may benifit...
Rusty.
--
Premature optmztion is rt of all evl. --DK
|