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: > > 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
