Re: [dpdk-dev] [RFC] ethdev: introduce copy_field rte flow action

[Thomas Monjalon <thomas@monjalon.net>]

07/01/2021 21:14, Alexander Kozyrev:
> > 07/01/2021 17:57, Alexander Kozyrev:
> > > > 07/01/2021 16:22, Alexander Kozyrev:
> > > > > > 07/01/2021 16:10, Alexander Kozyrev:
> > > > > > > > > > Thursday, January 7, 2021 10:18, Thomas Monjalon
> > > > > > <thomas@monjalon.net>
> > > > > > > > > > > RTE Flows API lacks the ability to save an arbitrary header field
> > in
> > > > > > > > > > > order to use it later for advanced packet manipulations.
> > Examples
> > > > > > > > > > > include the usage of VxLAN ID after the packet is decapsulated
> > or
> > > > > > > > > > > storing this ID inside the packet payload itself or swapping an
> > > > > > > > > > > arbitrary inner and outer packet fields.
> > > > > > > > > > >
> > > > > > > > > > > The idea is to allow a copy of a specified number of bits form
> > any
> > > > > > > > > > > packet header field into another header field:
> > > > > > > > > > > RTE_FLOW_ACTION_TYPE_COPY_FIELD with the structure
> > defined
> > > > > > below.
> > > > > > > > > > >
> > > > > > > > > > > struct rte_flow_action_copy_field {
> > > > > > > > > > > 	struct rte_flow_action_copy_data dest;
> > > > > > > > > > > 	struct rte_flow_action_copy_data src;
> > > > > > > > > > > 	uint16_t width;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > Arbitrary header field (as well as mark, metadata or tag values)
> > can
> > > > be
> > > > > > > > > > > used as both source and destination fields. This way we can save
> > an
> > > > > > > > > > > arbitrary header field by copying its value to a
> > tag/mark/metadata
> > > > or
> > > > > > > > > > > copy it into another header field directly. tag/mark/metadata
> > can
> > > > also
> > > > > > > > > > > be used as a value to be stored in an arbitrary packet header
> > field.
> > > > > > > > > > >
> > > > > > > > > > > struct rte_flow_action_copy_data {
> > > > > > > > > > > 	enum rte_flow_field_id field;
> > > > > > > > > > > 	uint16_t index;
> > > > > > > > > > > 	uint16_t offset;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > The rte_flow_field_id specifies the particular packet field (or
> > > > > > > > > > > tag/mark/metadata) to be used as a copy source or destination.
> > > > > > > > > > > The index gives access to inner packet headers or elements in
> > the
> > > > tags
> > > > > > > > > > > array. The offset allows to copy a packet field value into the
> > > > payload.
> > > > > > > > > >
> > > > > > > > > > So index is in reality the layer? How is it numbered exactly?
> > > > > > > > >
> > > > > > > > > It is a layer for packet fields, inner headers get higher number index.
> > > > > > > > > But is it also an index in the TAG array, so the name comes from it.
> > > > > > > >
> > > > > > > > Sorry it is not obvious.
> > > > > > > > Please describe the exact numbering in tunnel and VLAN cases.
> > > > > > > >
> > > > > > > > > > What is the field id if an offset is given?
> > > > > > > > >
> > > > > > > > > Field ID stays the same, you can specify a small offset to copy just a
> > > > few
> > > > > > bits
> > > > > > > > > from the entire packet field or a big offset to move to completely
> > > > different
> > > > > > > > area.
> > > > > > > >
> > > > > > > > I don't understand what is an offset then.
> > > > > > > > Isn't it the byte or bit where the copy start?
> > > > > > > > Do you handle sizes smaller than a byte?
> > > > > > >
> > > > > > > It is the bit offset, you can copy 20 bits out of 32 bits of IPv4 address
> > for
> > > > > > example.
> > > > > >
> > > > > > Now I'm confused.
> > > > > > You mean rte_flow_action_copy_data.offset is a bit offset?
> > > > >
> > > > > rte_flow_action_copy_data.offset and rte_flow_action_copy_field.width
> > > > > are measured in bits, right.
> > > >
> > > > So the offset is limited to 16 bits?
> > > > How can it be useful? Is it an offset starting from the specified field?
> > >
> > > Why 16? It can be up to 2^16=65536 bits. Do you think that is not enough?
> > 
> > Yes 8KB may be too small for huge packets.
> > I recommend 32 bits.
> Sounds good, will make it 32-bit in the implementation.
> 
> > > And it starts from the specific packet field pointed by the Field ID, correct.
> > 
> > I think it would be more useful as a global offset
> > starting from the first bit of the packet.
> The API gives you this flexibility when you specify None as the Field ID.
> But Field ID is useful when you don't want to calculate the offset by yourself.
> You can just say: I would like to copy IP address in the inner header (index 1),
> for example, and leave offset as 0 instead of trying to figure out where it is:
> set copy_field width 32 src field ipv4 index 1 offset 0 dst field tag index 0 offset 0

OK it makes sense.

I think you should better explain the calculations in the doxygen comments.