Hi Andrew, *Dekel* (I swear I'm not doing it on purpose, hopefully I won't
make that stupid mistake again :)
On Mon, Apr 08, 2019 at 04:53:54PM +0300, Andrew Rybchenko wrote:
> On 4/8/19 4:36 PM, Dekel Peled wrote:
> > Regarding Andrew's suggestion: "Shouldn't these action be
> > RTE_FLOW_ACTION_TYPE_MOD_TCP_{ACK,SEQ} with singed 32-bit integer parameter
> > (negative to decrement, positive to increment)?"
> > I will leave the actions as is, the action names indicate the operation
> > they perform.
>
> I think it is an overkill to have two actions for the purpose: DEC (value)
> == INC ((uint32_t)-value)
> If it is really important to have DEC and INC, please, make it clear from
> actions documentation why.
The main reason in my opinion is that a signed value may not be able to
represent an increment large enough for an unsigned value of the same bit
width.
This can be worked around by using a type larger than the underlying data
field (e.g. i64 for u32), but it will look confusing and is not an option
for the largest unsigned type we support (u64).
Another problem is what endian increment/decrement actions should use. There
are no dedicated endian types for signed values at the moment, and I'm not
sure we should define any.
This could be addressed by defining a third "SET" action to overwrite the
current value (even if unused) as this action will use the same type as
the two others and that of the underlying data (including endianness) for
consistency.
--
Adrien Mazarguil
6WIND
