Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier.

[Thomas Graf <tgraf@suug.ch>]

> If you implement the mothership match changes we discussed then it
> should go as a match (as opposed to action). As an action its yet
> another deferal for later cleanup.

What about this...

We introduce a new API tcf_exts which holds all the things on top of
a classifier. There might be several instaces per classifier, i.e. one
per filter for u32 and fw and one per hash bucket for route/tcindex,
etc.

The classifier no longer knows about action/police/meta/... you name it
but rather forwards the TLV TCA_..._EXTS to the extensions API. Backward
compatibility is provided in the API (very simple).

The extension infrastructure builds a tree to implement logic
expressions where each node can be one of the supported types.

The action code would be transformed to an extension which would
mean that there could be multiple action chains. Example:

 cls -+ meta indev=ppp0
      |    \ <and> meta assign nfmark=2
      |             \ <and> action:gact redirect
 <or> |
      \ meta nfmark=0x20
           \ <and> action:mirred

Every extension node has a unique handle in the namespace of the tree.
Deletion of a node results in deletion of all sub nodes.

Configuration must go via change routine of classifier or via tp->get()
and some generic way to retrieve extension handle from classifier.

Thoughts?