Document some simple rules for actions
Subsystems (3)
PATCH 3/3 Document some simple rules for actions
cheers,
jamal
[NET_DOC] Document some simple rules for actions
This patch adds documentation on what is expected of an action which branches away from the action-graph or when it needs to trample on actins. It also describes what is expected of users of such actions.
--- Documentation/networking/tc-actions-env-rules.txt | 29 +++++++++++++++++++++ 1 files changed, 29 insertions(+), 0 deletions(-)
Documentation/networking/tc-actions-env-rules.txt new file +29 -0
@@ -0,0 +1,29 @@ + +The "enviromental" rules for authors of any new tc actions are: + +1) If you stealeth or borroweth any packet thou shalt be branching +from the righteous path and thou shalt cloneth. + +For example if your action queues a packet to be processed later +or intentionaly branches by redirecting a packet then you need to +clone the packet. +There are certain fields in the skb tc_verd that need to be reset so we +avoid loops etc. A few are generic enough so much so that skb_act_clone() +resets them for you. So invoke skb_act_clone() rather than skb_clone() + +2) If you munge any packet thou shalt call skb_expand in the case +someone else is referencing the skb. After that you "own" the skb. +You must also tell us if it is ok to munge the packet (TC_OK2MUNGE), +this way any action downstream can stomp on the packet. + +3) dropping packets you dont own is a nono. You simply return +TC_ACT_SHOT to the caller and they will drop it. + +The "enviromental" rules for callers of actions (qdiscs etc) are: + +*) thou art responsible for freeing anything returned as being +TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is +returned then all is great and you dont need to do anything. + +Post on netdev if something is unclear. +
Signature · 1 line
1.4.4.1.gaed4
Documentation/networking/tc-actions-env-rules.txt line 17
Quoted 5 lines · jamal
+2) If you munge any packet thou shalt call
skb_expandin the caseDocumentation/networking/tc-actions-env-rules.txt new file +3
-0+someone else is referencing the skb. After that you "own" the skb. +You must also tell us if it is ok to munge the packet (TC_OK2MUNGE), +this way any action downstream can stomp on the packet.
Thanks for the documentation!
But I still think the distinction between skb_clone and skb_copy_header is wrong.
When you munge a packet, it's still going to go back up the stack and be processed along the same path. Therefore you should be calling pskb_expand_head.
In other words, this does not explain why skb_copy/pskb_copy and skb_copy_expand should differ from skb_clone. As far as I can see all these functions should behave in the same manner with respect to tc_verd.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtQuoted 6 lines · Herbert Xu
But I still think the distinction between
skb_cloneandskb_copy_headeris wrong.When you munge a packet, it's still going to go back up the stack and be processed along the same path. Therefore you should be calling
pskb_expand_head.
Dang, just noticed i said skb_expand() in the doc - is that the issue? I will resend that one patch.
We do call pskb_expand_head() - example look at act_pedit.c
Quoted 4 lines
In other words, this does not explain why skb_copy/pskb_copy and
skb_copy_expandshould differ fromskb_clone. As far as I can see all these functions should behave in the same manner with respect totc_verd
We need to avoid actions from infinetely looping (eg when they ask for being reclassified) in a directed graph. That loop ttl count must be reset to zero if we branch, because that is a new directed path. This is always true and therefore that field must always be reset.
I have a feeling i am going on a tangent if that doesnt respond to your comment above.
cheers,
jamal