On Mon, Aug 22, 2016 at 03:23:45PM -0700, Tom Herbert wrote: > On Mon, Aug 22, 2016 at 7:38 AM, Amir Vadai <a...@vadai.me> wrote: > > Hi, > > > > This patchset introduces iptunnel support using the TC subsystem. > > > > In the decap flow, it enables the user to redirect packets from a shared > > tunnel > > device and classify by outer and inner headers. The outer headers are > > extracted > > from the metadata and used by the flower filter. A new action act_iptunnel, > > releases the metadata. > > > > In the encap flow, act_iptunnel creates a metadata object to be used by the > > shared tunnel device. The actual redirection to the tunnel device is done > > using > > act_mirred. > > > > For example: > > $ tc qdisc add dev vnet0 ingress > > $ tc filter add dev vnet0 protocol ip parent ffff: \ > > flower \ > > ip_proto 1 \ > > action iptunnel encap \ > > src_ip 11.11.0.1 \ > > dst_ip 11.11.0.2 \ > > id 11 \ > > action mirred egress redirect dev vxlan0 > > > Is the device required to be a tunnel device? Consider that with LWT > we can perform this sort of encapsulation without requiring a special > device... > > Tom > Yes and no. This action is relevant only for a shared tunnel device. like the one you get with: $ ip link add vxlan0 type vxlan dstport 4789 external A user can add metadata using this action and redirect to any netdev, but only the shared tunnel netdev will do something with it.
Regarding LWT, in our use case we need to have classification in addition to the routing, have both encap and decap operations and be ready to add offloading to the API. For that, TC subsystem looked the most suiteable. Thanks, Amir [...]
