tc_verd vs. skb_clone

tc_verd vs. skb_clone

[Herbert Xu]

Hi Jamal:

I was wondering why we're not copying tc_verd as is in skb_clone.
In particular, this makes pskb_copy behave differently compared
to skb_clone and I can't find a justificatino for it.

Any ideas?

Also we don't seem to copy iif in copy_skb_header.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: tc_verd vs. skb_clone

[jamal]

On Fri, 2007-12-10 at 22:00 +0800, Herbert Xu wrote:
> Hi Jamal:
> 
> I was wondering why we're not copying tc_verd as is in skb_clone.
> In particular, this makes pskb_copy behave differently compared
> to skb_clone and I can't find a justificatino for it.
> 
> Any ideas?

In the case of an action branching (from a graph), they clone. In the
case they want to trample on an skb, they copy; otherwise it continues
processing in the graph with none of the above. In the clone case,
certain metadata needs reseting (like the "it is ok to munge on this
packet" to "it is _not_ ok to munge on it" etc). We allow the copy case 
leeway to do whatever it wants since it is going to tranple on the skb
and therefore reset nothing.
Would something more verbose in Documentation/net help to make this
clear?

If it is causing trouble, then one idea would be to move the resetting
to a wrapper function which calls clone first and then resets the other
fields. All actions currently cloning would need to be mod-ed to use
that call.

> Also we don't seem to copy iif in copy_skb_header.

I cant think of a good reason why it shouldnt be copied or recall
whether thats how its been from the begining. The reason probably it
hasnt mattered so far is everything that needs to write the iif never
copies.

cheers,
jamal