Re: [PATCH net-next 3/3] net/sched: Introduce act_iptunnel

On Mon, Aug 22, 2016 at 08:51:37PM +0200, Jiri Benc wrote:

On Mon, 22 Aug 2016 21:15:41 +0300, Or Gerlitz wrote:

quoted

Jiri B > I understand the motivation for the decap action. However, what would
Jiri B > happen if someone does not include it?

The MD set by the (say) vxlan device will not be "consumed" (cleared)
and would be keep travelling with the SKB

Of course it would. That's not what I meant by the question :-)

There are three options:

1. It does not matter, as the metadata_dst will be freed anyway before
   it reaches tx path. This means we do not need the 'decap' action.

2. We may run into problems like tx path seeing the metadata_dst that
   it should not see. This means either this situation or such
   configuration must be prevented somehow.

3. The metadata_dst can reach the tx path but it doesn't matter, as it
   would just mean the packet is encapsulated into the same outer
   headers it was received with or the metadata_dst would be ignored
   (for non-tunnel interfaces).

Which one is it? Quickly looking into the code, tcf_mirred calls
dev_queue_xmit which indicates it's either 2 or 3. If it's 3., it
should be explained in the patch description (especially the non-tunnel
interface case) and documented.

First, as you suspected it is (2) or (3). AFAIK the skb is injected by
act_mirred as is, with the metadata into the tx path.
I couldn't find a case where having the metadata on the skb matters.
Still, I would be very happy to hear what other people have to say about
it.

Anyway, this issue is orthogonal to this patchset...

 Jiri