Hi,

I have a few concerns with this API proposal,

1. The term ODP_PMR_OFFSET_ABS could be renamed as ODP_PMR_OFFSET_L2 as
this offset is from L2.
This would help some platforms which can support additional offset from
custom layer other than L2 and they can add additional Enum in their
private header file to enhance the feature.

2. This PMR term ODP_PMR_OFFSET_ABS_L2 could NOT be added in the middle of
a PMR chain as most platforms parse the packets in a linear order and it
might not be feasible to come back and check the L2 starting offset lets
say after parsing any L3 or L2 parameter. I would like to know if this
behavior is common across all platforms. Any comments are welcome here.

3. In Cavium implementation only one of this term ODP_PMR_OFFSET_ABS_L2 can
be attached to a single pktio interface. Would like to know if other HWs
have this same limitation or that any number of this terms can be attached.

Regards,
Bala

On 2 July 2015 at 17:08, Maxim Uvarov <maxim.uva...@linaro.org> wrote:

> That is the change which we discussed on Sprint.
>
> Bala, Petri - no objection to include it?
>
> Thank you,
> Maxim.
>
>
>
> On 07/02/15 13:40, Benoît Ganne wrote:
>
>> Ping.
>>
>> On 06/18/2015 08:53 PM, Benoît Ganne wrote:
>>
>>> The application can now specify a packet offset
>>> in PMR rules. This offset is absolute from the
>>> frame start. It is used to extract the PMR value.
>>>
>>> This is useful to support arbitrary backplane
>>> protocols and extensions.
>>>
>>> Signed-off-by: Benoît Ganne <bga...@kalray.eu>
>>> ---
>>>   include/odp/api/classification.h | 25 +++++++++++++++++++++++++
>>>   1 file changed, 25 insertions(+)
>>>
>>> diff --git a/include/odp/api/classification.h
>>> b/include/odp/api/classification.h
>>> index f597b26..7b84e78 100644
>>> --- a/include/odp/api/classification.h
>>> +++ b/include/odp/api/classification.h
>>> @@ -215,6 +215,8 @@ typedef enum odp_pmr_term {
>>>       ODP_PMR_IPSEC_SPI,    /**< IPsec session
>>> identifier(*val=uint32_t)*/
>>>       ODP_PMR_LD_VNI,        /**< NVGRE/VXLAN network identifier
>>>                   (*val=uint32_t)*/
>>> +    ODP_PMR_OFFSET_ABS,    /**< User-defined offset/val_sz to match
>>> +                (*val=uint8_t[val_sz]*/
>>>        /** Inner header may repeat above values with this offset */
>>>       ODP_PMR_INNER_HDR_OFF = 32
>>> @@ -240,6 +242,27 @@ odp_pmr_t odp_pmr_create(odp_pmr_term_e term, const
>>> void *val,
>>>                const void *mask, uint32_t val_sz);
>>>    /**
>>> + * Create a packet match rule with absolute offset, mask and value
>>> + *
>>> + * @param[in]    term    One of the enumerated values supported
>>> + * @param[in]    offset    Absolute value in the packet
>>> + * @param[in]    val     Value to match against the packet header
>>> + *            in native byte order.
>>> + * @param[in]    mask    Mask to indicate which bits of the header
>>> + *            should be matched ('1') and
>>> + *            which should be ignored ('0')
>>> + * @param[in]    val_sz  Size of the val and mask arguments,
>>> + *            that must match the value size requirement of the
>>> + *            specific term.
>>> + *
>>> + * @return        Handle of the matching rule
>>> + * @retval        ODP_PMR_INVAL on failure
>>> + */
>>> +odp_pmr_t odp_pmr_create_offset_abs(odp_pmr_term_e term,
>>> +                    unsigned int offset, const void *val,
>>> +                    const void *mask, uint32_t val_sz);
>>> +
>>> +/**
>>>    * Invalidate a packet match rule and vacate its resources
>>>    *
>>>    * @param[in]    pmr_id    Identifier of the PMR to be destroyed
>>> @@ -302,6 +325,8 @@ typedef struct odp_pmr_match_t {
>>>       const void    *val;    /**< Value to be matched */
>>>       const void    *mask;    /**< Masked set of bits to be matched */
>>>       unsigned int    val_sz;     /**< Size of the term value */
>>> +    unsigned int    offset;  /**< User-defined offset in packet
>>> +                            only valid if term == ODP_PMR_OFFSET */
>>>   } odp_pmr_match_t;
>>>    /**
>>>
>>>
>>
>>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to