> 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
> > > > > <tho...@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
> > > > > > > > > Can we say that a field id can always be replaced by an
> > > > > > > > > offset?
> > > > > > > >
> > > > > > > > Not really. You can use offset to jump around packet fields for
> > > > > > > > sure,
> but
> > > it
> > > > > is
> > > > > > > going to be
> > > > > > > > hard and cumbersome to calculate all the offsets for that.
> > > > > > > > Field ID is
> > > much
> > > > > > > more convenient.
> > > > > > >
> > > > > > > I think it depends for who.
> > > > > > > For some use cases, it may be easier to pass an offset.
> > > > > > > For some drivers, it may be more efficient to directly manage
> > > > > > > offsets.
> > > > > >
> > > > > > It is possible with this RFC, driver can choose what to use: id
> > > > > > and/or
> offset.
> > > > >
> > > >
> > > > > We can set field and index to 0, and use only offset?
> > > > Yes, I'm not inending to put any restrictions against that.
> > > > > Then it is a byte offset from the beginning mbuf.data?
> > > > Yes, but it is still bit offset, not byte offset.
>
>
>
>
