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
