Re: [dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
On Thu, Dec 15, 2016 at 12:20:36PM +, Ferruh Yigit wrote:
> On 12/8/2016 3:19 PM, Adrien Mazarguil wrote:
> > Hi Ferruh,
> >
> > On Fri, Dec 02, 2016 at 04:58:53PM +, Ferruh Yigit wrote:
> >> Hi Adrien,
> >>
> >> On 11/16/2016 4:23 PM, Adrien Mazarguil wrote:
> >>> As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> >>> described in [3] (also pasted below), here is the first non-draft series
> >>> for this new API.
> >>>
> >>> Its capabilities are so generic that its name had to be vague, it may be
> >>> called "Generic flow API", "Generic flow interface" (possibly shortened
> >>> as "GFI") to refer to the name of the new filter type, or "rte_flow" from
> >>> the prefix used for its public symbols. I personally favor the latter.
> >>>
> >>> While it is currently meant to supersede existing filter types in order
> >>> for
> >>> all PMDs to expose a common filtering/classification interface, it may
> >>> eventually evolve to cover the following ideas as well:
> >>>
> >>> - Rx/Tx offloads configuration through automatic offloads for specific
> >>> packets, e.g. performing checksum on TCP packets could be expressed with
> >>> an egress rule with a TCP pattern and a kind of checksum action.
> >>>
> >>> - RSS configuration (already defined actually). Could be global or per
> >>> rule
> >>> depending on hardware capabilities.
> >>>
> >>> - Switching configuration for devices with many physical ports; rules
> >>> doing
> >>> both ingress and egress could even be used to completely bypass software
> >>> if supported by hardware.
> >>>
> >>> [1] http://dpdk.org/ml/archives/dev/2016-July/043365.html
> >>> [2] http://dpdk.org/ml/archives/dev/2016-August/045383.html
> >>> [3] http://dpdk.org/ml/archives/dev/2016-November/050044.html
> >>>
> >>> Changes since RFC v2:
> >>>
> >>> - New separate VLAN pattern item (previously part of the ETH definition),
> >>> found to be much more convenient.
> >>>
> >>> - Removed useless "any" field from VF pattern item, the same effect can be
> >>> achieved by not providing a specification structure.
> >>>
> >>> - Replaced bit-fields from the VXLAN pattern item to avoid endianness
> >>> conversion issues on 24-bit fields.
> >>>
> >>> - Updated struct rte_flow_item with a new "last" field to create inclusive
> >>> ranges. They are defined as the interval between (spec & mask) and
> >>> (last & mask). All three parameters are optional.
> >>>
> >>> - Renamed ID action MARK.
> >>>
> >>> - Renamed "queue" fields in actions QUEUE and DUP to "index".
> >>>
> >>> - "rss_conf" field in RSS action is now const.
> >>>
> >>> - VF action now uses a 32 bit ID like its pattern item counterpart.
> >>>
> >>> - Removed redundant struct rte_flow_pattern, API functions now expect
> >>> struct
> >>> rte_flow_item lists terminated by END items.
> >>>
> >>> - Replaced struct rte_flow_actions for the same reason, with struct
> >>> rte_flow_action lists terminated by END actions.
> >>>
> >>> - Error types (enum rte_flow_error_type) have been updated and the cause
> >>> pointer in struct rte_flow_error is now const.
> >>>
> >>> - Function prototypes (rte_flow_create, rte_flow_validate) have also been
> >>> updated for clarity.
> >>>
> >>> Additions:
> >>>
> >>> - Public wrapper functions rte_flow_{validate|create|destroy|flush|query}
> >>> are now implemented in rte_flow.c, with their symbols exported and
> >>> versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added.
> >>>
> >>> - A separate header (rte_flow_driver.h) has been added for driver-side
> >>> functionality, in particular struct rte_flow_ops which contains PMD
> >>> callbacks returned by RTE_ETH_FILTER_GENERIC query.
> >>>
> >>> - testpmd now exposes most of this API through the new "flow" command.
> >>>
> >>> What remains to be done:
> >>>
> >>> - Using endian-aware integer types (rte_beX_t) where necessary for
> >>> clarity.
> >>>
> >>> - API documentation (based on RFC).
> >>>
> >>> - testpmd flow command documentation (although context-aware command
> >>> completion should already help quite a bit in this regard).
> >>>
> >>> - A few pattern item / action properties cannot be configured yet
> >>> (e.g. rss_conf parameter for RSS action) and a few completions
> >>> (e.g. possible queue IDs) should be added.
> >>>
> >>
> >> <...>
> >>
> >> I was trying to check driver filter API patches, but hit a few compiler
> >> errors with this patchset.
> >>
> >> [1] clang complains about variable bitfield value changed from -1 to 1.
> >> Which is correct, but I guess that is intentional, but I don't know how
> >> to tell this to clang?
> >>
> >> [2] shred library compilation error, because of missing rte_flow_flush
> >> in rte_ether_version.map file
> >>
> >> [3] bunch of icc compilation errors, almost all are same type:
> >> error #188: enumerated type mixed with another type
> >
> > Thanks for the report, I'll attempt to address them all in v2.
>
> Hi Adrien,
>
> I wou
Re: [dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
On 12/8/2016 3:19 PM, Adrien Mazarguil wrote:
> Hi Ferruh,
>
> On Fri, Dec 02, 2016 at 04:58:53PM +, Ferruh Yigit wrote:
>> Hi Adrien,
>>
>> On 11/16/2016 4:23 PM, Adrien Mazarguil wrote:
>>> As previously discussed in RFC v1 [1], RFC v2 [2], with changes
>>> described in [3] (also pasted below), here is the first non-draft series
>>> for this new API.
>>>
>>> Its capabilities are so generic that its name had to be vague, it may be
>>> called "Generic flow API", "Generic flow interface" (possibly shortened
>>> as "GFI") to refer to the name of the new filter type, or "rte_flow" from
>>> the prefix used for its public symbols. I personally favor the latter.
>>>
>>> While it is currently meant to supersede existing filter types in order for
>>> all PMDs to expose a common filtering/classification interface, it may
>>> eventually evolve to cover the following ideas as well:
>>>
>>> - Rx/Tx offloads configuration through automatic offloads for specific
>>> packets, e.g. performing checksum on TCP packets could be expressed with
>>> an egress rule with a TCP pattern and a kind of checksum action.
>>>
>>> - RSS configuration (already defined actually). Could be global or per rule
>>> depending on hardware capabilities.
>>>
>>> - Switching configuration for devices with many physical ports; rules doing
>>> both ingress and egress could even be used to completely bypass software
>>> if supported by hardware.
>>>
>>> [1] http://dpdk.org/ml/archives/dev/2016-July/043365.html
>>> [2] http://dpdk.org/ml/archives/dev/2016-August/045383.html
>>> [3] http://dpdk.org/ml/archives/dev/2016-November/050044.html
>>>
>>> Changes since RFC v2:
>>>
>>> - New separate VLAN pattern item (previously part of the ETH definition),
>>> found to be much more convenient.
>>>
>>> - Removed useless "any" field from VF pattern item, the same effect can be
>>> achieved by not providing a specification structure.
>>>
>>> - Replaced bit-fields from the VXLAN pattern item to avoid endianness
>>> conversion issues on 24-bit fields.
>>>
>>> - Updated struct rte_flow_item with a new "last" field to create inclusive
>>> ranges. They are defined as the interval between (spec & mask) and
>>> (last & mask). All three parameters are optional.
>>>
>>> - Renamed ID action MARK.
>>>
>>> - Renamed "queue" fields in actions QUEUE and DUP to "index".
>>>
>>> - "rss_conf" field in RSS action is now const.
>>>
>>> - VF action now uses a 32 bit ID like its pattern item counterpart.
>>>
>>> - Removed redundant struct rte_flow_pattern, API functions now expect
>>> struct
>>> rte_flow_item lists terminated by END items.
>>>
>>> - Replaced struct rte_flow_actions for the same reason, with struct
>>> rte_flow_action lists terminated by END actions.
>>>
>>> - Error types (enum rte_flow_error_type) have been updated and the cause
>>> pointer in struct rte_flow_error is now const.
>>>
>>> - Function prototypes (rte_flow_create, rte_flow_validate) have also been
>>> updated for clarity.
>>>
>>> Additions:
>>>
>>> - Public wrapper functions rte_flow_{validate|create|destroy|flush|query}
>>> are now implemented in rte_flow.c, with their symbols exported and
>>> versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added.
>>>
>>> - A separate header (rte_flow_driver.h) has been added for driver-side
>>> functionality, in particular struct rte_flow_ops which contains PMD
>>> callbacks returned by RTE_ETH_FILTER_GENERIC query.
>>>
>>> - testpmd now exposes most of this API through the new "flow" command.
>>>
>>> What remains to be done:
>>>
>>> - Using endian-aware integer types (rte_beX_t) where necessary for clarity.
>>>
>>> - API documentation (based on RFC).
>>>
>>> - testpmd flow command documentation (although context-aware command
>>> completion should already help quite a bit in this regard).
>>>
>>> - A few pattern item / action properties cannot be configured yet
>>> (e.g. rss_conf parameter for RSS action) and a few completions
>>> (e.g. possible queue IDs) should be added.
>>>
>>
>> <...>
>>
>> I was trying to check driver filter API patches, but hit a few compiler
>> errors with this patchset.
>>
>> [1] clang complains about variable bitfield value changed from -1 to 1.
>> Which is correct, but I guess that is intentional, but I don't know how
>> to tell this to clang?
>>
>> [2] shred library compilation error, because of missing rte_flow_flush
>> in rte_ether_version.map file
>>
>> [3] bunch of icc compilation errors, almost all are same type:
>> error #188: enumerated type mixed with another type
>
> Thanks for the report, I'll attempt to address them all in v2.
Hi Adrien,
I would like to remind that there are driver patch sets depends to this
patch.
New version of this patch should give some time to drivers to re-do (if
required) the patchsets before integration deadline.
Thanks,
ferruh
> However icc
> error #188 looks like a pain, I think I can work around it but do we really
> not tolera
Re: [dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
On 12/8/2016 3:19 PM, Adrien Mazarguil wrote:
> Hi Ferruh,
>
> On Fri, Dec 02, 2016 at 04:58:53PM +, Ferruh Yigit wrote:
>> Hi Adrien,
>>
>> On 11/16/2016 4:23 PM, Adrien Mazarguil wrote:
>>> As previously discussed in RFC v1 [1], RFC v2 [2], with changes
>>> described in [3] (also pasted below), here is the first non-draft series
>>> for this new API.
>>>
>>> Its capabilities are so generic that its name had to be vague, it may be
>>> called "Generic flow API", "Generic flow interface" (possibly shortened
>>> as "GFI") to refer to the name of the new filter type, or "rte_flow" from
>>> the prefix used for its public symbols. I personally favor the latter.
>>>
>>> While it is currently meant to supersede existing filter types in order for
>>> all PMDs to expose a common filtering/classification interface, it may
>>> eventually evolve to cover the following ideas as well:
>>>
>>> - Rx/Tx offloads configuration through automatic offloads for specific
>>> packets, e.g. performing checksum on TCP packets could be expressed with
>>> an egress rule with a TCP pattern and a kind of checksum action.
>>>
>>> - RSS configuration (already defined actually). Could be global or per rule
>>> depending on hardware capabilities.
>>>
>>> - Switching configuration for devices with many physical ports; rules doing
>>> both ingress and egress could even be used to completely bypass software
>>> if supported by hardware.
>>>
>>> [1] http://dpdk.org/ml/archives/dev/2016-July/043365.html
>>> [2] http://dpdk.org/ml/archives/dev/2016-August/045383.html
>>> [3] http://dpdk.org/ml/archives/dev/2016-November/050044.html
>>>
>>> Changes since RFC v2:
>>>
>>> - New separate VLAN pattern item (previously part of the ETH definition),
>>> found to be much more convenient.
>>>
>>> - Removed useless "any" field from VF pattern item, the same effect can be
>>> achieved by not providing a specification structure.
>>>
>>> - Replaced bit-fields from the VXLAN pattern item to avoid endianness
>>> conversion issues on 24-bit fields.
>>>
>>> - Updated struct rte_flow_item with a new "last" field to create inclusive
>>> ranges. They are defined as the interval between (spec & mask) and
>>> (last & mask). All three parameters are optional.
>>>
>>> - Renamed ID action MARK.
>>>
>>> - Renamed "queue" fields in actions QUEUE and DUP to "index".
>>>
>>> - "rss_conf" field in RSS action is now const.
>>>
>>> - VF action now uses a 32 bit ID like its pattern item counterpart.
>>>
>>> - Removed redundant struct rte_flow_pattern, API functions now expect
>>> struct
>>> rte_flow_item lists terminated by END items.
>>>
>>> - Replaced struct rte_flow_actions for the same reason, with struct
>>> rte_flow_action lists terminated by END actions.
>>>
>>> - Error types (enum rte_flow_error_type) have been updated and the cause
>>> pointer in struct rte_flow_error is now const.
>>>
>>> - Function prototypes (rte_flow_create, rte_flow_validate) have also been
>>> updated for clarity.
>>>
>>> Additions:
>>>
>>> - Public wrapper functions rte_flow_{validate|create|destroy|flush|query}
>>> are now implemented in rte_flow.c, with their symbols exported and
>>> versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added.
>>>
>>> - A separate header (rte_flow_driver.h) has been added for driver-side
>>> functionality, in particular struct rte_flow_ops which contains PMD
>>> callbacks returned by RTE_ETH_FILTER_GENERIC query.
>>>
>>> - testpmd now exposes most of this API through the new "flow" command.
>>>
>>> What remains to be done:
>>>
>>> - Using endian-aware integer types (rte_beX_t) where necessary for clarity.
>>>
>>> - API documentation (based on RFC).
>>>
>>> - testpmd flow command documentation (although context-aware command
>>> completion should already help quite a bit in this regard).
>>>
>>> - A few pattern item / action properties cannot be configured yet
>>> (e.g. rss_conf parameter for RSS action) and a few completions
>>> (e.g. possible queue IDs) should be added.
>>>
>>
>> <...>
>>
>> I was trying to check driver filter API patches, but hit a few compiler
>> errors with this patchset.
>>
>> [1] clang complains about variable bitfield value changed from -1 to 1.
>> Which is correct, but I guess that is intentional, but I don't know how
>> to tell this to clang?
>>
>> [2] shred library compilation error, because of missing rte_flow_flush
>> in rte_ether_version.map file
>>
>> [3] bunch of icc compilation errors, almost all are same type:
>> error #188: enumerated type mixed with another type
>
> Thanks for the report, I'll attempt to address them all in v2. However icc
> error #188 looks like a pain, I think I can work around it but do we really
> not tolerate the use of normal integers inside enum fields in DPDK?
If this warning is not improving the code, and community agree on it, it
is possible to disable warning by adding "-wd188" to test-pmd Makefile
for ICC compiler.
Re: [dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
Hi Ferruh,
On Fri, Dec 02, 2016 at 04:58:53PM +, Ferruh Yigit wrote:
> Hi Adrien,
>
> On 11/16/2016 4:23 PM, Adrien Mazarguil wrote:
> > As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> > described in [3] (also pasted below), here is the first non-draft series
> > for this new API.
> >
> > Its capabilities are so generic that its name had to be vague, it may be
> > called "Generic flow API", "Generic flow interface" (possibly shortened
> > as "GFI") to refer to the name of the new filter type, or "rte_flow" from
> > the prefix used for its public symbols. I personally favor the latter.
> >
> > While it is currently meant to supersede existing filter types in order for
> > all PMDs to expose a common filtering/classification interface, it may
> > eventually evolve to cover the following ideas as well:
> >
> > - Rx/Tx offloads configuration through automatic offloads for specific
> > packets, e.g. performing checksum on TCP packets could be expressed with
> > an egress rule with a TCP pattern and a kind of checksum action.
> >
> > - RSS configuration (already defined actually). Could be global or per rule
> > depending on hardware capabilities.
> >
> > - Switching configuration for devices with many physical ports; rules doing
> > both ingress and egress could even be used to completely bypass software
> > if supported by hardware.
> >
> > [1] http://dpdk.org/ml/archives/dev/2016-July/043365.html
> > [2] http://dpdk.org/ml/archives/dev/2016-August/045383.html
> > [3] http://dpdk.org/ml/archives/dev/2016-November/050044.html
> >
> > Changes since RFC v2:
> >
> > - New separate VLAN pattern item (previously part of the ETH definition),
> > found to be much more convenient.
> >
> > - Removed useless "any" field from VF pattern item, the same effect can be
> > achieved by not providing a specification structure.
> >
> > - Replaced bit-fields from the VXLAN pattern item to avoid endianness
> > conversion issues on 24-bit fields.
> >
> > - Updated struct rte_flow_item with a new "last" field to create inclusive
> > ranges. They are defined as the interval between (spec & mask) and
> > (last & mask). All three parameters are optional.
> >
> > - Renamed ID action MARK.
> >
> > - Renamed "queue" fields in actions QUEUE and DUP to "index".
> >
> > - "rss_conf" field in RSS action is now const.
> >
> > - VF action now uses a 32 bit ID like its pattern item counterpart.
> >
> > - Removed redundant struct rte_flow_pattern, API functions now expect
> > struct
> > rte_flow_item lists terminated by END items.
> >
> > - Replaced struct rte_flow_actions for the same reason, with struct
> > rte_flow_action lists terminated by END actions.
> >
> > - Error types (enum rte_flow_error_type) have been updated and the cause
> > pointer in struct rte_flow_error is now const.
> >
> > - Function prototypes (rte_flow_create, rte_flow_validate) have also been
> > updated for clarity.
> >
> > Additions:
> >
> > - Public wrapper functions rte_flow_{validate|create|destroy|flush|query}
> > are now implemented in rte_flow.c, with their symbols exported and
> > versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added.
> >
> > - A separate header (rte_flow_driver.h) has been added for driver-side
> > functionality, in particular struct rte_flow_ops which contains PMD
> > callbacks returned by RTE_ETH_FILTER_GENERIC query.
> >
> > - testpmd now exposes most of this API through the new "flow" command.
> >
> > What remains to be done:
> >
> > - Using endian-aware integer types (rte_beX_t) where necessary for clarity.
> >
> > - API documentation (based on RFC).
> >
> > - testpmd flow command documentation (although context-aware command
> > completion should already help quite a bit in this regard).
> >
> > - A few pattern item / action properties cannot be configured yet
> > (e.g. rss_conf parameter for RSS action) and a few completions
> > (e.g. possible queue IDs) should be added.
> >
>
> <...>
>
> I was trying to check driver filter API patches, but hit a few compiler
> errors with this patchset.
>
> [1] clang complains about variable bitfield value changed from -1 to 1.
> Which is correct, but I guess that is intentional, but I don't know how
> to tell this to clang?
>
> [2] shred library compilation error, because of missing rte_flow_flush
> in rte_ether_version.map file
>
> [3] bunch of icc compilation errors, almost all are same type:
> error #188: enumerated type mixed with another type
Thanks for the report, I'll attempt to address them all in v2. However icc
error #188 looks like a pain, I think I can work around it but do we really
not tolerate the use of normal integers inside enum fields in DPDK?
> [1]
> =
> .../app/test-pmd/cmdline_flow.c:944:16: error: implicit truncation from
> 'int' to bitfield changes value from -1 to 1
> [-Werror,-Wbitfield-constant-conversion]
> .args
Re: [dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
Hi Adrien,
On 11/16/2016 4:23 PM, Adrien Mazarguil wrote:
> As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> described in [3] (also pasted below), here is the first non-draft series
> for this new API.
>
> Its capabilities are so generic that its name had to be vague, it may be
> called "Generic flow API", "Generic flow interface" (possibly shortened
> as "GFI") to refer to the name of the new filter type, or "rte_flow" from
> the prefix used for its public symbols. I personally favor the latter.
>
> While it is currently meant to supersede existing filter types in order for
> all PMDs to expose a common filtering/classification interface, it may
> eventually evolve to cover the following ideas as well:
>
> - Rx/Tx offloads configuration through automatic offloads for specific
> packets, e.g. performing checksum on TCP packets could be expressed with
> an egress rule with a TCP pattern and a kind of checksum action.
>
> - RSS configuration (already defined actually). Could be global or per rule
> depending on hardware capabilities.
>
> - Switching configuration for devices with many physical ports; rules doing
> both ingress and egress could even be used to completely bypass software
> if supported by hardware.
>
> [1] http://dpdk.org/ml/archives/dev/2016-July/043365.html
> [2] http://dpdk.org/ml/archives/dev/2016-August/045383.html
> [3] http://dpdk.org/ml/archives/dev/2016-November/050044.html
>
> Changes since RFC v2:
>
> - New separate VLAN pattern item (previously part of the ETH definition),
> found to be much more convenient.
>
> - Removed useless "any" field from VF pattern item, the same effect can be
> achieved by not providing a specification structure.
>
> - Replaced bit-fields from the VXLAN pattern item to avoid endianness
> conversion issues on 24-bit fields.
>
> - Updated struct rte_flow_item with a new "last" field to create inclusive
> ranges. They are defined as the interval between (spec & mask) and
> (last & mask). All three parameters are optional.
>
> - Renamed ID action MARK.
>
> - Renamed "queue" fields in actions QUEUE and DUP to "index".
>
> - "rss_conf" field in RSS action is now const.
>
> - VF action now uses a 32 bit ID like its pattern item counterpart.
>
> - Removed redundant struct rte_flow_pattern, API functions now expect
> struct
> rte_flow_item lists terminated by END items.
>
> - Replaced struct rte_flow_actions for the same reason, with struct
> rte_flow_action lists terminated by END actions.
>
> - Error types (enum rte_flow_error_type) have been updated and the cause
> pointer in struct rte_flow_error is now const.
>
> - Function prototypes (rte_flow_create, rte_flow_validate) have also been
> updated for clarity.
>
> Additions:
>
> - Public wrapper functions rte_flow_{validate|create|destroy|flush|query}
> are now implemented in rte_flow.c, with their symbols exported and
> versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added.
>
> - A separate header (rte_flow_driver.h) has been added for driver-side
> functionality, in particular struct rte_flow_ops which contains PMD
> callbacks returned by RTE_ETH_FILTER_GENERIC query.
>
> - testpmd now exposes most of this API through the new "flow" command.
>
> What remains to be done:
>
> - Using endian-aware integer types (rte_beX_t) where necessary for clarity.
>
> - API documentation (based on RFC).
>
> - testpmd flow command documentation (although context-aware command
> completion should already help quite a bit in this regard).
>
> - A few pattern item / action properties cannot be configured yet
> (e.g. rss_conf parameter for RSS action) and a few completions
> (e.g. possible queue IDs) should be added.
>
<...>
I was trying to check driver filter API patches, but hit a few compiler
errors with this patchset.
[1] clang complains about variable bitfield value changed from -1 to 1.
Which is correct, but I guess that is intentional, but I don't know how
to tell this to clang?
[2] shred library compilation error, because of missing rte_flow_flush
in rte_ether_version.map file
[3] bunch of icc compilation errors, almost all are same type:
error #188: enumerated type mixed with another type
Thanks,
ferruh
[1]
=
.../app/test-pmd/cmdline_flow.c:944:16: error: implicit truncation from
'int' to bitfield changes value from -1 to 1
[-Werror,-Wbitfield-constant-conversion]
.args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_raw,
relative)),
^
.../app/test-pmd/cmdline_flow.c:282:42: note: expanded from macro
'ARGS_ENTRY_BF'
.mask = (const void *)&(const s){ .f = -1 }, \
^~
.../app/test-pmd/cmdline_flow.c:269:49: note: expanded from macro 'ARGS'
#define ARGS(...) (const struct arg *const []){ __VA_ARGS__, NULL, }
[dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
Hi Yulong, On Mon, Nov 28, 2016 at 10:03:53AM +, Pei, Yulong wrote: > Hi Adrien, > > I think that you already did test for your patchset, do you have any > automated test scripts can be shared for validation since there did not have > testpmd flow command documentation yet? No automated script, at least not yet. I intend to submit v2 with extra API documentation, testpmd commands with examples of expected behavior and output, as well as fixes for the issues pointed out by Nelio. -- Adrien Mazarguil 6WIND
[dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
Hi Adrien,
I think that you already did test for your patchset, do you have any
automated test scripts can be shared for validation since there did not have
testpmd flow command documentation yet?
Best Regards
Yulong Pei
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Adrien Mazarguil
Sent: Thursday, November 17, 2016 12:23 AM
To: dev at dpdk.org
Cc: Thomas Monjalon ; De Lara Guarch, Pablo
; Olivier Matz
Subject: [dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
As previously discussed in RFC v1 [1], RFC v2 [2], with changes described in
[3] (also pasted below), here is the first non-draft series for this new API.
Its capabilities are so generic that its name had to be vague, it may be called
"Generic flow API", "Generic flow interface" (possibly shortened as "GFI") to
refer to the name of the new filter type, or "rte_flow" from the prefix used
for its public symbols. I personally favor the latter.
While it is currently meant to supersede existing filter types in order for all
PMDs to expose a common filtering/classification interface, it may eventually
evolve to cover the following ideas as well:
- Rx/Tx offloads configuration through automatic offloads for specific
packets, e.g. performing checksum on TCP packets could be expressed with
an egress rule with a TCP pattern and a kind of checksum action.
- RSS configuration (already defined actually). Could be global or per rule
depending on hardware capabilities.
- Switching configuration for devices with many physical ports; rules doing
both ingress and egress could even be used to completely bypass software
if supported by hardware.
[1] http://dpdk.org/ml/archives/dev/2016-July/043365.html
[2] http://dpdk.org/ml/archives/dev/2016-August/045383.html
[3] http://dpdk.org/ml/archives/dev/2016-November/050044.html
Changes since RFC v2:
- New separate VLAN pattern item (previously part of the ETH definition),
found to be much more convenient.
- Removed useless "any" field from VF pattern item, the same effect can be
achieved by not providing a specification structure.
- Replaced bit-fields from the VXLAN pattern item to avoid endianness
conversion issues on 24-bit fields.
- Updated struct rte_flow_item with a new "last" field to create inclusive
ranges. They are defined as the interval between (spec & mask) and
(last & mask). All three parameters are optional.
- Renamed ID action MARK.
- Renamed "queue" fields in actions QUEUE and DUP to "index".
- "rss_conf" field in RSS action is now const.
- VF action now uses a 32 bit ID like its pattern item counterpart.
- Removed redundant struct rte_flow_pattern, API functions now expect
struct
rte_flow_item lists terminated by END items.
- Replaced struct rte_flow_actions for the same reason, with struct
rte_flow_action lists terminated by END actions.
- Error types (enum rte_flow_error_type) have been updated and the cause
pointer in struct rte_flow_error is now const.
- Function prototypes (rte_flow_create, rte_flow_validate) have also been
updated for clarity.
Additions:
- Public wrapper functions rte_flow_{validate|create|destroy|flush|query}
are now implemented in rte_flow.c, with their symbols exported and
versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added.
- A separate header (rte_flow_driver.h) has been added for driver-side
functionality, in particular struct rte_flow_ops which contains PMD
callbacks returned by RTE_ETH_FILTER_GENERIC query.
- testpmd now exposes most of this API through the new "flow" command.
What remains to be done:
- Using endian-aware integer types (rte_beX_t) where necessary for clarity.
- API documentation (based on RFC).
- testpmd flow command documentation (although context-aware command
completion should already help quite a bit in this regard).
- A few pattern item / action properties cannot be configured yet
(e.g. rss_conf parameter for RSS action) and a few completions
(e.g. possible queue IDs) should be added.
Adrien Mazarguil (22):
ethdev: introduce generic flow API
cmdline: add support for dynamic tokens
cmdline: add alignment constraint
app/testpmd: implement basic support for rte_flow
app/testpmd: add flow command
app/testpmd: add rte_flow integer support
app/testpmd: add flow list command
app/testpmd: add flow flush command
app/testpmd: add flow destroy command
app/testpmd: add flow validate/create commands
app/testpmd: add flow query command
app/testpmd: add rte_flow item spec handler
app/testpmd: add rte_flow item spec prefix length
app/testpmd: add rte_flow bit-field support
app/testpmd: add item any to flow command
app/testpmd: add various items to flow command
app/testpmd: add item raw to flow command
app/testpmd: add items eth/vlan to flow command
app/testpmd: add items ipv4/ipv6 to
[dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
Hi, I found some small issues: - In rte_flow_error_set(), *cause argument should be const to avoid a compilation error when we implement it. - In port_flow_create(), the flow is not stored in the pf structure which ends by providing a null pointer to port_flow_destroy() function. Regards, -- N?lio Laranjeiro 6WIND
[dpdk-dev] [PATCH 00/22] Generic flow API (rte_flow)
As previously discussed in RFC v1 [1], RFC v2 [2], with changes
described in [3] (also pasted below), here is the first non-draft series
for this new API.
Its capabilities are so generic that its name had to be vague, it may be
called "Generic flow API", "Generic flow interface" (possibly shortened
as "GFI") to refer to the name of the new filter type, or "rte_flow" from
the prefix used for its public symbols. I personally favor the latter.
While it is currently meant to supersede existing filter types in order for
all PMDs to expose a common filtering/classification interface, it may
eventually evolve to cover the following ideas as well:
- Rx/Tx offloads configuration through automatic offloads for specific
packets, e.g. performing checksum on TCP packets could be expressed with
an egress rule with a TCP pattern and a kind of checksum action.
- RSS configuration (already defined actually). Could be global or per rule
depending on hardware capabilities.
- Switching configuration for devices with many physical ports; rules doing
both ingress and egress could even be used to completely bypass software
if supported by hardware.
[1] http://dpdk.org/ml/archives/dev/2016-July/043365.html
[2] http://dpdk.org/ml/archives/dev/2016-August/045383.html
[3] http://dpdk.org/ml/archives/dev/2016-November/050044.html
Changes since RFC v2:
- New separate VLAN pattern item (previously part of the ETH definition),
found to be much more convenient.
- Removed useless "any" field from VF pattern item, the same effect can be
achieved by not providing a specification structure.
- Replaced bit-fields from the VXLAN pattern item to avoid endianness
conversion issues on 24-bit fields.
- Updated struct rte_flow_item with a new "last" field to create inclusive
ranges. They are defined as the interval between (spec & mask) and
(last & mask). All three parameters are optional.
- Renamed ID action MARK.
- Renamed "queue" fields in actions QUEUE and DUP to "index".
- "rss_conf" field in RSS action is now const.
- VF action now uses a 32 bit ID like its pattern item counterpart.
- Removed redundant struct rte_flow_pattern, API functions now expect
struct
rte_flow_item lists terminated by END items.
- Replaced struct rte_flow_actions for the same reason, with struct
rte_flow_action lists terminated by END actions.
- Error types (enum rte_flow_error_type) have been updated and the cause
pointer in struct rte_flow_error is now const.
- Function prototypes (rte_flow_create, rte_flow_validate) have also been
updated for clarity.
Additions:
- Public wrapper functions rte_flow_{validate|create|destroy|flush|query}
are now implemented in rte_flow.c, with their symbols exported and
versioned. Related filter type RTE_ETH_FILTER_GENERIC has been added.
- A separate header (rte_flow_driver.h) has been added for driver-side
functionality, in particular struct rte_flow_ops which contains PMD
callbacks returned by RTE_ETH_FILTER_GENERIC query.
- testpmd now exposes most of this API through the new "flow" command.
What remains to be done:
- Using endian-aware integer types (rte_beX_t) where necessary for clarity.
- API documentation (based on RFC).
- testpmd flow command documentation (although context-aware command
completion should already help quite a bit in this regard).
- A few pattern item / action properties cannot be configured yet
(e.g. rss_conf parameter for RSS action) and a few completions
(e.g. possible queue IDs) should be added.
Adrien Mazarguil (22):
ethdev: introduce generic flow API
cmdline: add support for dynamic tokens
cmdline: add alignment constraint
app/testpmd: implement basic support for rte_flow
app/testpmd: add flow command
app/testpmd: add rte_flow integer support
app/testpmd: add flow list command
app/testpmd: add flow flush command
app/testpmd: add flow destroy command
app/testpmd: add flow validate/create commands
app/testpmd: add flow query command
app/testpmd: add rte_flow item spec handler
app/testpmd: add rte_flow item spec prefix length
app/testpmd: add rte_flow bit-field support
app/testpmd: add item any to flow command
app/testpmd: add various items to flow command
app/testpmd: add item raw to flow command
app/testpmd: add items eth/vlan to flow command
app/testpmd: add items ipv4/ipv6 to flow command
app/testpmd: add L4 items to flow command
app/testpmd: add various actions to flow command
app/testpmd: add queue actions to flow command
MAINTAINERS|4 +
app/test-pmd/Makefile |1 +
app/test-pmd/cmdline.c | 32 +
app/test-pmd/cmdline_flow.c| 2581 +++
app/test-pmd/config.c | 484 +
app/test-pmd/csumonly.c|1 +
app/test-pmd/flowgen.c |1 +
app/test-pmd/icmpecho.c|1 +
app/test-pmd/ieee1588fwd.c |1
