On 6/3/2021 10:27 AM, Ori Kam wrote:
> Hi Andrew,
>
>> -Original Message-
>> From: Andrew Rybchenko
>>
>> Hi Ori,
>>
>> Cc Eli and Ilya since I think OvS could be interested in the feature.
>>
>> On 6/3/21 11:25 AM, Ori Kam wrote:
>>> Hi Andrew,
>>>
-Original Message-
Fr
Hi Aman,
On 6/14/21 3:42 PM, Singh, Aman Deep wrote:
> Hi Ivan,
>
> As a suggestion, can we add a check for debug log_level in
> "rte_flow_snprint" itself.
I see the reason, but I think it a bad idea to put the check
inside the function. If calling function cares, it should do
the check.
> So w
Hi Ivan,
Another option is to log these structures values (rte_flow_attr ,
rte_flow_item, rte_flow_action) as it is.
Latter run a parsing script on these logs, to convets them into
meaningful flow items.
The completeness of the solution will depend on how well script is
maintained.
Rega
Hi Ivan,
As a suggestion, can we add a check for debug log_level in
"rte_flow_snprint" itself.
So we can avoid CPU time, in cases where we don't want these logs.
On 5/27/2021 1:55 PM, Ivan Malov wrote:
DPDK applications (for example, OvS) or tests which use RTE
flow API need to log created
Hi Andrew,
> -Original Message-
> From: Andrew Rybchenko
>
> Hi Ori,
>
> Cc Eli and Ilya since I think OvS could be interested in the feature.
>
> On 6/3/21 11:25 AM, Ori Kam wrote:
> > Hi Andrew,
> >
> >> -Original Message-
> >> From: Andrew Rybchenko
> >>
> >> Hi Ori,
> >>
>
Hi Ori,
Cc Eli and Ilya since I think OvS could be interested in the
feature.
On 6/3/21 11:25 AM, Ori Kam wrote:
> Hi Andrew,
>
>> -Original Message-
>> From: Andrew Rybchenko
>>
>> Hi Ori,
>>
>> On 6/2/21 4:32 PM, Ori Kam wrote:
>>> Hi Ivan,
>>>
-Original Message-
Fro
Hi Andrew,
> -Original Message-
> From: Andrew Rybchenko
>
> Hi Ori,
>
> On 6/2/21 4:32 PM, Ori Kam wrote:
> > Hi Ivan,
> >
> >> -Original Message-
> >> From: Ivan Malov
> >>
> >> Hi Ori,
> >>
> >> Your review efforts are much appreciated. I understand your concern
> >> about t
On Sun, 30 May 2021 07:27:32 +
Ori Kam wrote:
> > + retv = snprintf(buf + *nb_chars_total, write_size_max,
> > + " %02x:%02x:%02x:%02x:%02x:%02x",
> > + ab[0], ab[1], ab[2], ab[3], ab[4], ab[5]);
please use existing rte_ether_format_addr instead of anoth
Hi Ori,
On 6/2/21 4:32 PM, Ori Kam wrote:
> Hi Ivan,
>
>> -Original Message-
>> From: Ivan Malov
>>
>> Hi Ori,
>>
>> Your review efforts are much appreciated. I understand your concern
>> about the partial item/action coverage, but there are some points to be
>> considered when addressin
Hi Ivan,
> -Original Message-
> From: Ivan Malov
>
> Hi Ori,
>
> Your review efforts are much appreciated. I understand your concern
> about the partial item/action coverage, but there are some points to be
> considered when addressing it:
> - It's anyway hardly possible to use the prin
On Tue, 1 Jun 2021 17:17:24 +0300
Ivan Malov wrote:
> Hi Stephen,
>
> I agree that the API rte_flow_snprint() itself would look better if it
> provided the number of characters in its return value, like snprintf
> does. However, with respect to all internal helpers, this wouldn't be
> that cl
Hi Stephen,
I agree that the API rte_flow_snprint() itself would look better if it
provided the number of characters in its return value, like snprintf
does. However, with respect to all internal helpers, this wouldn't be
that clear and simple: one would have to update the buffer pointer and
Hi Ori,
Your review efforts are much appreciated. I understand your concern
about the partial item/action coverage, but there are some points to be
considered when addressing it:
- It's anyway hardly possible to use the printed flow directly in
testpmd if it contains "opaque", or "PMD-specific
On Sun, 30 May 2021 07:27:32 +
Ori Kam wrote:
> >
> > DPDK applications (for example, OvS) or tests which use RTE flow API need to
> > log created or rejected flow rules to help to recognise what goes right or
> > wrong. From this standpoint, testpmd-compliant format is nice for the
> > purp
Hi Ivan,
First nice idea and thanks for the picking up the ball.
Before a detail review,
The main thing I'm concerned about is that this print will be partially
supported,
I know that you covered this issue by printing unknown for unsupported
item/actions,
but this will mean that it is enough
DPDK applications (for example, OvS) or tests which use RTE
flow API need to log created or rejected flow rules to help
to recognise what goes right or wrong. From this standpoint,
testpmd-compliant format is nice for the purpose because it
allows to copy-paste the flow rules and debug using testpm
16 matches
Mail list logo
