[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e0dd21a0904121631u3fc7c676r12eb7e71fe87e02b@mail.gmail.com>
Date: Mon, 13 Apr 2009 01:31:14 +0200
From: Johann Baudy <johann.baudy@...-log.net>
To: Evgeniy Polyakov <zbr@...emap.net>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Patrick McHardy <kaber@...sh.net>, jamal <hadi@...erus.ca>
Subject: Re: [PATCH] TX_RING and packet mmap
Thanks Evgeniy,
So if my understanding is correct, there is no way to get original
fragment address in destructor using skb fragment page/data.
Then,
I can't use fragments due to skb_linearize
I can't hide pointer into skb data due to skb_copy.
I can't rely on other fields of skb.
IMHO, using skb pointer requires too much cpu resources (parsing
headers to identify the right buffer...)
So what can I do except using a new field?
What do you think about adding a new field that is always linked to destructor?
I mean adding a generic new field skb->destructor_arg.
Currently if someone want to change destructor, it stores old
destructor before substitution; and executes it at the end of new
destructor. (ex: dev_gso_skb_destructor(struct sk_buff *skb))
Can we just add same mechanism for a new argument?
If someone needs destructor_arg, it saves the old value somewhere; and
restores it before calling old destructor (in the new destructor).
This way everybody can forward data to his destructor properly.
Is it conceivable?
Thanks for your help,
Johann
--
Johann Baudy
johaahn@...il.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists