On 3/20/25 15:29, Eli Britstein wrote:
> 
> 
>> -----Original Message-----
>> From: Ilya Maximets <i.maxim...@ovn.org>
>> Sent: Thursday, 20 March 2025 14:59
>> To: Roi Dayan <r...@nvidia.com>; d...@openvswitch.org
>> Cc: Maor Dickman <ma...@nvidia.com>; Eli Britstein <el...@nvidia.com>;
>> i.maxim...@ovn.org
>> Subject: Re: [ovs-dev] [PATCH 0/3] Support tunnel-void action
>>
>> External email: Use caution opening links or attachments
>>
>>
>> On 3/20/25 10:26, Roi Dayan via dev wrote:
>>> Upon tunnel output failure, due to routing failure for example, add a
>>> tunnel-void action. This action does not do anything, but it appears
>>> in the dp-flows for better visibility for that case.
>>
>> Hi, Eli.  Thanks for the set!
>>
>> I see the issue and agree that we should have better visibility for it, but 
>> we
>> shouldn't add new actions.  We have an explicit drop action exactly for cases
>> like this.  So, instead of a new action, we need to add a new xlate_error 
>> type
>> and generate an explicit drop action (if supported by the datapath) with this
>> error as a drop reason.  And we already have counting of such drops with
>> coverage counters in the userspace datapath, we'll just need to add a new
>> one for a new drop reason.  See dp_update_drop_action_counter() function.
>>
>> Note: new xlate errors should be added to the end of the enum.
> 
> Hi Ilya,
> 
> The "tnl-void" is not a "drop", but a "no-op" action. Only if there are no 
> other actions, it is translated to drop.
> In other cases, it is not.
> For example, consider a flow that follows this openflow (that fails routing):
> In_port=<P1>,actions=<vxlan0>,<P2>
> 
> With the absence of "tnl-void", the datapath flow is simply 
> in_port=<P1>,actions=<P2>
> I omit the other default matches, just to explain.
> 
> With those patches, the datapath flow will be 
> in_port=<P1>,actions=tnl_void,<P2>

If the tunnel is configured properly datapath actions will be:

  actions=clone(tnl_push(),<out-port>),<P2>

If not, it will be:

  actions=clone(drop(reason)),<P2>.

Tunnel push changes the packet, so the clone is necessary.  Drop
also "changes" the packet, so yes, the clone is necessary as well.

So, it's a very similar action structure.  Optimizing for a flow
translation failure by not including the clone() in the drop case
doesn't seem to make a lot of sense.  If needed, we may optimize
the clone(drop) in the datapth while executing the action, so it
will also mostly be a no-op, though it seems a little unnecessary.

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to