Re: [PATCH 2/3] ethdev: add new rte_mtr API for traffic metering and policing

[Hemant Agrawal <hemant.agrawal@nxp.com>]

Hi Cristian,

On 9/4/2017 8:02 PM, Dumitrescu, Cristian wrote:
> <snip>...
>
>>> +
>>> +/**
>>> + * Traffic metering algorithms
>>> + */
>>> +enum rte_mtr_algorithm {
>>> +	/**< Single Rate Three Color Marker (srTCM) - IETF RFC 2697. */
>>> +	RTE_MTR_SRTCM_RFC2697 = 0,
>>> +
>>> +	/**< Two Rate Three Color Marker (trTCM) - IETF RFC 2698. */
>>> +	RTE_MTR_TRTCM_RFC2698,
>>
>> will you please also add following here
>> 1. RFC-4115-A differentiated service two-rate three-color marker with
>> efficient handling of in-profile traffic
>> 2. Pass Through Mode- This mode does not implement differentiated
>> services. It can be used for some applications to block/pass selected
>> flows and set a constant color for these flows. The default (disabled)
>> mode is color-aware pass-through with no dropping of packets.
>> - In color-aware mode, packet pre-color is copied to the packet color
>> - In color-blind mode, the default color is programmable per profile
>> - Configurable next module and command per packet color. Each color
>> action can be programmed to pass or drop the packet.
>>
>
> Yes, will add both. The trTCM from RFC 4115 was already on my list, adding the pass-through mode makes sense to me as well.
>
> <snip>...
>
>>> +/**
>>> + * Meter profile delete
>>> + *
>>> + * Delete an existing meter profile. This operation fails when there is
>>> + * currently at least one user (i.e. MTR object) of this profile.
>>> + *
>>
>> Do you want to do this checking at library level or at driver level?
>> Same profile can be used by two distinct drivers!
>>
>> This is applicable for other APIs as well. Your current API
>> implementation is mostly pass-through. A stateful will be better.
>>
>
> Yes, the same meter profiles can potentially be shared for a group of ethdev ports, but unfortunately we cannot do this with the current ethdev API, which is per port with no sharing ability between groups of ports.
>
> Here we are lucky to have just a read-only configuration template that needs to be shared amongst ports, so the quick workaround is to define the same profile for each port at the expense of some (small) work duplication. Hopefully this is OK with you?
>
Is that mean you will create the meter profile template first and then 
apply/remove that on a port?

how about adding a use-count to the profile?

On a different lines, can we do following
1. Metering profile is not applied to a port.  Metering object maintain 
the use-count.
2. metering object is applied to the port, which in turn contains 
metering profile.

Regards,
Hemant