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

[Slava Ovsiienko]

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Thursday, January 7, 2021 19:06
> To: Alexander Kozyrev <akozyrev at nvidia.com>
> Cc: dev at dpdk.org; Slava Ovsiienko <viacheslavo at nvidia.com>; Ori Kam
> <orika at nvidia.com>; ferruh.yigit at intel.com;
> andrew.rybchenko at oktetlabs.ru; ajit.khaparde at broadcom.com;
> jerinj at marvell.com
> Subject: Re: [dpdk-dev] [RFC] ethdev: introduce copy_field rte flow action
> 
> 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 at 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.
> 
> > 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.

M-m-m, sorry, I think this anchor (the first bit of the packet) is not applicable in general due to
the field position in the packet is flexible and varying. For example, packet may contain 
VLAN tag, IP header options, TCP options, or may not, and absolute offset 
(from the packet beginning) does not work well. 

Hence, to unambiguously specify the desired part (as bit field) of the packet we need the following indices:
- protocol field, we do it with field enum, and field index (if any - in case if we have multiple
similar items in the packet - say, inner or outer IP, or array of metadata tags)
- the bit offset in the field - to specify the beginning of our target bitfield
- the bitfield width in bits - to specify how many bits we would like to proceed

With this bitfield addressing approach we get the opportunity to manipulate with
bitfields in the almost any protocol fields. For example we could copy congestion
control bits from inner IP header to outer one. We can have fine handling the bits 
in metadata, and so on.

> > > > > > > > > Can we say that a field id can always be replaced by an offset?
Theoretically we could consider defining some fixed packet structure and use
offsets from there, say:
MAC_DST is 0
MAC_SRC is 6
MAC_TYPE is 12
VLAN_TAG is 14
VLAN_TYPE is 16
....

But, there are to many variations in the possible packet formats - tagged/untagged,
CVLANs, IP4/6, IP options/extensions, the huge zoopark of tunnel... It would introduce
and ambiguity and would require to predefine a lot of packet formats. 

With best regards,
Slava