On Tue, Feb 23, 2016 at 8:12 AM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 02/23/2016 03:39 PM, Jamal Hadi Salim wrote: >> >> On 16-02-23 08:32 AM, Daniel Borkmann wrote: >>> >>> On 02/23/2016 01:49 PM, Jamal Hadi Salim wrote: >>>> >>>> From: Jamal Hadi Salim <j...@mojatatu.com> >>>> >>>> This action allows for a sending side to encapsulate arbitrary metadata >>>> which is decapsulated by the receiving end. >>>> The sender runs in encoding mode and the receiver in decode mode. >>>> Both sender and receiver must specify the same ethertype. >>>> At some point we hope to have a registered ethertype and we'll >>>> then provide a default so the user doesnt have to specify it. >>>> For now we enforce the user specify it. >>>> >>>> Lets show example usage where we encode icmp from a sender towards >>>> a receiver with an skbmark of 17; both sender and receiver use >>>> ethertype of 0xdead to interop. >>> >>> >>> On a conceptual level, as this is an L2 encap with TLVs, why not having >>> a normal device driver for this like we have in other cases that would >>> encode/decode the meta data itself? >> >> >> netdevs dont scale for large number of policies. See why ipsec which >> at one point was implemented using a netdev and why xfrm eventually >> was chosen as the way forward. Or look at the recent lwt >> effort. > > > Sure, I'm just saying that it could conceptionally be similar to the > collect metadata idea just on L2 in your case. The encoding/decoding > and transport of the information is actually not overly tc specific > at least from the code that's shown so far, just a thought. >
TC offers more flexibility than netdev, but on the other hand, TC actions sit too deep in TC, you know, netdev -> qdisc -> filter -> action...
