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

[Ori Kam <orika@nvidia.com>]

Hi

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

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

Regards,
Ori