?
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
Hi Kevin,
On Wed, Nov 30, 2016 at 05:47:17PM +, Kevin Traynor wrote:
> Hi Adrien,
>
> On 11/16/2016 04:23 PM, Adrien Mazarguil wrote:
> > This new API supersedes all the legacy filter types described in
> > rte_eth_ctrl.h. It is slightly higher level and as a result re
ription, I still think there is an issue,
please see my reply to Konstantin [1].
[1] http://dpdk.org/ml/archives/dev/2016-December/050970.html
--
Adrien Mazarguil
6WIND
gt; > quirks to struct rte_eth_desc_lim (and friends) which are currently quietly
> > handled by TX burst functions.
>
> Ok, so MLX PMD is not affected by these changes and tx_prep for MLX can be
> safely
> set to NULL, correct?
Correct, actually the rest of this message should be in a separate
thread. From the MLX side, there is no issue with tx_prepare().
--
Adrien Mazarguil
6WIND
then,
"it is OK, we do not need any checksum preparation for TSO".
Actually I do not think we'll ever need tx_prep() unless we add our own
quirks to struct rte_eth_desc_lim (and friends) which are currently quietly
handled by TX burst functions.
--
Adrien Mazarguil
6WIND
gt; RTE_PMD_EXPORT_NAME(net_mlx5, __COUNTER__);
> RTE_PMD_REGISTER_PCI_TABLE(net_mlx5, mlx5_pci_id_map);
> +RTE_PMD_REGISTER_KMOD_DEP(net_mlx5, "* igb_uio | uio_pci_generic | vfio");
RTE_PMD_REGISTER_KMOD_DEP(net_mlx5, "* ib_uverbs & mlx5_core & mlx5_ib");
--
Adrien Mazarguil
6WIND
Hi Beilei,
On Fri, Nov 18, 2016 at 06:36:31AM +, Xing, Beilei wrote:
> Hi Adrien,
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Adrien Mazarguil
> > Sent: Thursday, November 17, 2016 12:23 AM
> > To: dev at dpdk.or
idx = rxq->cq_ci + 1;
> uint16_t end = zip->cq_ci;
>
> while (idx != end) {
> --
> 2.1.4
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
t; + wqe = &(*txq->wqes)[ntohs(cqe->wqe_counter) &
> ((1 << txq->wqe_n) - 1)].hdr;
> elts_tail = wqe->ctrl[3];
> assert(elts_tail < (1 << txq->wqe_n));
> --
> 2.1.4
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
__rte_mbuf_raw_free(pkt);
> - pkt = seg;
> + pkt = rep;
> }
> break;
> }
> --
> 2.1.4
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
- QUEUE: assign packets to a given queue index.
- DUP: duplicate packets to a given queue index.
- RSS: spread packets among several queues.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 152 +++
1 file changed, 152 insertions(+)
diff
- MARK: attach 32 bit value to packets.
- FLAG: flag packets.
- DROP: drop packets.
- COUNT: enable counters for a rule.
- PF: redirect packets to physical device function.
- VF: redirect packets to virtual device function.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 121
Add the ability to match a few properties of common L4[.5] protocol
headers:
- ICMP: type and code.
- UDP: source and destination ports.
- TCP: source and destination ports.
- SCTP: source and destination ports.
- VXLAN: network identifier.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd
Add the ability to match basic fields from IPv4 and IPv6 headers (source
and destination addresses only).
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 177 +++
1 file changed, 177 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b
These pattern items match basic Ethernet headers (source, destination and
type) and related 802.1Q/ad VLAN headers.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 126 +++
1 file changed, 126 insertions(+)
diff --git a/app/test-pmd
: byte string to look for.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 206 +++
1 file changed, 206 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index c61e31e..6f2f26c 100644
--- a/app/test-pmd
- PF: match packets addressed to the physical function.
- VF: match packets addressed to a virtual function ID.
- PORT: device-specific physical port index to use.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 53
1 file changed, 53
This pattern item matches any protocol in place of the current layer and
has two properties:
- min: minimum number of layers covered (0 or more).
- max: maximum number of layers covered (0 means infinity).
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 30
Several rte_flow structures expose bit-fields that cannot be set in a
generic fashion at byte level. Add bit-mask support to handle them.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 59
1 file changed, 59 insertions(+)
diff --git
Generating bit-masks from prefix lengths is often more convenient than
providing them entirely (e.g. to define IPv4 and IPv6 subnets).
This commit adds the "prefix" operator that assigns generated bit-masks to
any pattern item specification field.
Signed-off-by: Adrien Mazarguil
---
ask: sets bit-mask affecting both spec and last from arbitrary value.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 110 +++
1 file changed, 110 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index e70e
Syntax:
flow query {port_id} {rule_id} {action}
Query a specific action of an existing flow rule.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline.c | 3 +
app/test-pmd/cmdline_flow.c | 121 ++-
2 files changed, 123 insertions(+), 1 deletion
not match.
- PASSTHRU: action that leaves packets up for additional processing by
subsequent flow rules.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline.c | 14 ++
app/test-pmd/cmdline_flow.c | 314 ++-
2 files changed, 327 insertions(+), 1
Syntax:
flow destroy {port_id} rule {rule_id} [...]
Destroy a given set of flow rules associated with a port.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline.c | 3 ++
app/test-pmd/cmdline_flow.c | 106 ++-
2 files changed, 108 insertions
Syntax:
flow flush {port_id}
Destroy all flow rules on a port.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline.c | 3 +++
app/test-pmd/cmdline_flow.c | 43 +++-
2 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd
Syntax:
flow list {port_id} [group {group_id}] [...]
List configured flow rules on a port. Output can optionally be limited to a
given set of group identifiers.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline.c | 4 ++
app/test-pmd/cmdline_flow.c | 141
Parse all integer types and handle conversion to network byte order in a
single function.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline_flow.c | 148 +++
1 file changed, 148 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd
Managing generic flow API functions from command line requires the use of
dynamic tokens for convenience as flow rules are not fixed and cannot be
defined statically.
This commit adds specific flexible parser code and object for a new "flow"
command in separate file.
Signed-off-
Add basic management functions for the generic flow API (validate, create,
destroy, flush, query and list). Flow rule objects and properties are
arranged in lists associated with each port.
Signed-off-by: Adrien Mazarguil
---
app/test-pmd/cmdline.c | 1 +
app/test-pmd/config.c | 484
This prevents sigbus errors on architectures that cannot handle unexpected
unaligned accesses to the output buffer.
Signed-off-by: Adrien Mazarguil
---
lib/librte_cmdline/cmdline_parse.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/librte_cmdline
).
Because no structures are modified (existing fields are reused), this
commit has no impact on the current ABI.
Signed-off-by: Adrien Mazarguil
---
lib/librte_cmdline/cmdline_parse.c | 60 +
lib/librte_cmdline/cmdline_parse.h | 21
2 files changed, 74
is self-standing, no need to look up elsewhere.
Existing filter types will be deprecated and removed in the near future.
Signed-off-by: Adrien Mazarguil
---
MAINTAINERS| 4 +
lib/librte_ether/Makefile | 3 +
lib/librte_ether/rte_eth_ctrl.h| 1
.
- 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 completio
mentation (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
6WIND
On Fri, Nov 04, 2016 at 06:36:30AM +, Lu, Wenzhuo wrote:
> Hi Adrien,
>
> > -Original Message-
> > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> > Sent: Wednesday, November 2, 2016 11:21 PM
> > To: Lu, Wenzhuo
> > Cc: Ananyev, K
se_16_11.rst | 136
> ++---
> 2 files changed, 114 insertions(+), 30 deletions(-)
>
> --
> 2.1.4
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
> drivers/net/mlx4/mlx4.c | 21 --
> drivers/net/mlx5/mlx5_prm.h | 37 +-
> drivers/net/mlx5/mlx5_rxtx.c | 93
>
> 3 files changed, 87 insertions(+), 64 deletions(-)
>
> --
> 2.1.4
Thanks
uint8_t *)raw, (uint8_t *)addr);
> + memcpy((uint8_t *)raw, ((uint8_t *)addr), 16);
> length -= MLX5_WQE_DWORD_SIZE;
> addr += MLX5_WQE_DWORD_SIZE;
> /* Replace the Ethernet type by the VLAN if necessary. */
> --
> 1.8.3.1
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
Hi Wei,
On Wed, Nov 02, 2016 at 05:27:50AM +, Zhao1, Wei wrote:
> Hi All,
> Now we are planning for an sample application for Generic flow
> filtering API feature, and I have finished the RFC for this example app.
> Now Adrien Mazarguil has send v2 version of Generic flow
>
16.04.
> tcpdump_reset_code_reassembly_failed.pcap: sniff packets by tcpdump on 16.11
> reset_code_reassembly_successful_.jpg: reassembly a packets successful detail
> info
> dpdk16.11_reassembly_failed.jpg: reassembly a packets failed detail info
>
--
Adrien Mazarguil
6WIND
t longer!
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Adrien Mazarguil
> > Sent: Friday, September 30, 2016 1:11 AM
> > To: dev at dpdk.org
> > Cc: Thomas Monjalon
> > Subject: Re: [dpdk-dev] [RFC v2] Generic flow
> >
; Cc: dev at dpdk.org; Morten Br?rup
> > Subject: Re: [dpdk-dev] mbuf changes
> >
> > Hi Olivier,
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> > > Sent: Tuesday, October 25, 201
gt;mtu
> + ))
Let's move poor "))" to the end of the previous line.
> + dev->data->dev_conf.rxmode.jumbo_frame = 1;
> if ((dev->data->dev_conf.rxmode.jumbo_frame) &&
> (dev->data->dev_conf.rxmode.max_rx_pkt_len >
>(mb_len - RTE_PKTMBUF_HEADROOM))) {
> --
> 1.9.1
Besides the above comment:
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
H_RXQ_IPV6 |
> - 1 << HASH_RXQ_ETH |
> 0,
> .per_vlan = 1,
> },
> --
> 1.9.1
(NACK)
While technically correct, looks like this patch sometimes break IPv6
multicast traffic as well, let's drop it until we figure out the reason.
--
Adrien Mazarguil
6WIND
:14 PM
> > To: Adrien Mazarguil
> > Cc: Morten Br?rup; Wiles, Keith; dev at dpdk.org; Olivier Matz; Oleg
> > Kuporosov
> > Subject: Re: [dpdk-dev] mbuf changes
> >
> > On Tue, Oct 25, 2016 at 01:04:44PM +0200, Adrien Mazarguil wrote:
> > > On Tue, Oct 2
On Tue, Oct 25, 2016 at 12:11:04PM +0200, Morten Br?rup wrote:
> Comments inline.
>
> Med venlig hilsen / kind regards
> - Morten Br?rup
>
>
> > -Original Message-
> > From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> > Sent
more about latency than throughput, Oleg found that using the second cache
line for this purpose had a noticeable impact [1].
[1] http://dpdk.org/ml/archives/dev/2016-October/049237.html
--
Adrien Mazarguil
6WIND
On Wed, Oct 19, 2016 at 10:31:48AM +0100, Bruce Richardson wrote:
> On Mon, Oct 17, 2016 at 04:18:59PM +0200, Adrien Mazarguil wrote:
> > On Mon, Oct 17, 2016 at 02:52:39PM +0100, Ferruh Yigit wrote:
> > > Hi Adrien,
> > >
> > > On 10/17/2016 1:56 PM,
)
> >
> > Signed-off-by: Olivier Gournet
>
> According your comment on previous version of it, I think you have your
> Ack on this patch, but can you please confirm?
Yes it's fine, thanks.
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
quot;)
>
> Signed-off-by: Nelio Laranjeiro
Acked-by: Adrien Mazarguil
> ---
> drivers/net/mlx5/mlx5_rxq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
> index b9a5fe6..fe27d22 1006
t; primary_txq->elts_n,
> primary_txq_ctrl->socket,
> NULL) == 0) {
> --
> 2.1.4
--
Adrien Mazarguil
6WIND
Hi Wei,
On Tue, Oct 11, 2016 at 01:47:53AM +, Zhao1, Wei wrote:
> Hi Adrien Mazarguil,
> There is a struct rte_flow_action_rss in rte_flow.txt, the member
> rss_conf is a pointer type, is there any convenience in using pointer?
> Why not using struct rte_eth_rss_conf r
Hi Wei,
On Mon, Oct 10, 2016 at 09:42:53AM +, Zhao1, Wei wrote:
> Hi Adrien Mazarguil,
>
> In your v2 version of rte_flow.txt , there is an action type
> RTE_FLOW_ACTION_TYPE_MARK, but there is no definition of struct
> rte_flow_action_mark.
> And there is an de
uot;
> +#define MLX5_DRIVER_NAME "net_mlx5"
>
> /* Maximum number of simultaneous MAC addresses. */
> #define MLX5_MAX_MAC_ADDRESSES 128
> --
> 2.7.4
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
; @@ -773,7 +773,7 @@ struct rte_cryptodev_sym_session {
> } __rte_aligned(8);
> /**< Public symmetric session details */
>
> - char _private[];
> + __extension__ char _private[0];
> /**< Private session material */
> };
>
> --
> 2.7.4
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
On Wed, Sep 14, 2016 at 09:33:18PM +0200, Luke Gorrie wrote:
> Hi Adrien,
>
> On 14 September 2016 at 16:30, Adrien Mazarguil 6wind.com>
> wrote:
>
> > Your interpretation is correct (this is intentional and not a bug).
> >
>
> Thanks very much for clarif
on the PCI bus. This feature is currently
supported by the ConnectX-4 Lx family of adapters.
--
Adrien Mazarguil
6WIND
type [-Wcast-qual]
> > ((type *) (((char *) (p)) - offsetof(type, member)))
> >
> >The verbs.h version of container_of is same with dpdk one, I am not able
> >to find why one gives warning but other not.
>
> Thanks for highlighting. I am setting up my environment and will have a
> look.
This warning is a known issue in the Verbs header that will be addressed
eventually. It occurs even without Shreyansh's patch (more likely when
CONFIG_RTE_LIBRTE_MLX4_DEBUG and/or CONFIG_RTE_LIBRTE_MLX5_DEBUG are
enabled).
Your container_of() macro is fine, no need to spend time on this.
--
Adrien Mazarguil
6WIND
've removed it from test-build.sh, people will have to run it manually like
check-git-log.sh, updated v5 accordingly.
--
Adrien Mazarguil
6WIND
(like check-git-log.sh and friends) after
making changes to exported header files.
Signed-off-by: Adrien Mazarguil
---
MAINTAINERS | 1 +
scripts/check-includes.sh | 286 +
2 files changed, 287 insertions(+)
diff --git a/MAINTAINERS b
Arch-specific functions not defined for all architectures (missing on x86
in this case) and not used anywhere should not expose a prototype.
This commit prevents the following error:
error: `rte_mov48' declared `static' but never defined
Signed-off-by: Adrien Mazarguil
---
lib/librte_eal
__VA_ARGS__ with an extra dummy argument to format strings.
This commit prevents the following errors:
error: ISO C does not permit named variadic macros
Signed-off-by: Adrien Mazarguil
---
lib/librte_cryptodev/rte_cryptodev.h | 32 ++---
lib/librte_cryptodev
to `enum' types
Signed-off-by: Adrien Mazarguil
---
lib/librte_eal/common/include/generic/rte_cpuflags.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h
b/lib/librte_eal/common/include/generic/rte_cpuflags.h
index c1da357..71321f3 100644
_addr' has incomplete type
error: `CHAR_BIT' undeclared here (not in a function)
error: `struct [...]' declared inside parameter list
error: unknown type name `uint8_t'
Signed-off-by: Adrien Mazarguil
---
lib/librte_cfgfile/rte_cfgfile.h | 2 ++
lib/librte_cmdline
by default.
This commit prevents the following errors:
error: ISO C99 doesn't support unnamed structs/unions
error: struct has no named members
Signed-off-by: Adrien Mazarguil
---
lib/librte_cryptodev/rte_crypto.h | 2 ++
lib/librte_cryptodev/rte_crypto_sym.h
extension
Note: the standard does not require implementations to issue a diagnostic
message with these, and such errors do not occur with recent GCC or clang
versions. However, GCC 4.7 is still common and using the extension keyword
is easier than checking compiler version.
Signed-off-by: Adrien
the following errors:
error: ISO C forbids zero-size array `[...]'
Signed-off-by: Adrien Mazarguil
---
lib/librte_acl/rte_acl.h | 2 +-
lib/librte_cryptodev/rte_cryptodev.h | 2 +-
lib/librte_cryptodev/rte_cryptodev_pmd.h
to range of `int'
Signed-off-by: Adrien Mazarguil
---
lib/librte_eal/common/include/rte_memory.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/common/include/rte_memory.h
b/lib/librte_eal/common/include/rte_memory.h
index d9e8c21..12e0ebb 100644
--- a/lib/librte_eal/common
expressions
Signed-off-by: Adrien Mazarguil
---
lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h | 3 ++-
lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h | 3 ++-
lib/librte_eal/common/include/arch/x86/rte_memcpy.h| 4 ++--
lib/librte_eal/common/include/arch/x86/rte_vect.h | 6
extern "C"
blocks for files that already do that (Jan, fixing these was too much
work for this patchset so I settled on this solution in the meantime).
- Updated headlines to address check-git-log.sh complaints.
Adrien Mazarguil (10):
lib: work around braced-groups within expressions
lib:
://rawgit.com/6WIND/rte_flow/master/rte_flow.html
PDF version:
https://rawgit.com/6WIND/rte_flow/master/rte_flow.pdf
Git tree:
https://github.com/6WIND/rte_flow
Signed-off-by: Adrien Mazarguil
---
lib/librte_ether/Makefile | 2 +
lib/librte_ether/rte_flow.h | 941
Hi All,
Thanks to many for the positive and constructive feedback I've received so
far. Here is the updated specification (v0.7) at last.
I've attempted to address as many comments as possible but could not
process them all just yet. A new section "Future evolutions" has been
added for the
> Iwould appreciate any suggestions and guidance.
Well fortunately these errors are also present in v2.2.0 and should have
been addressed since v16.07 by the following commit:
http://dpdk.org/browse/dpdk/commit/?id=d06c608c013c36711e7a693b3fece68a93ae4369
You can either upgrade to v16.07, back-port this commit yourself or wait for
an update from Mellanox.
--
Adrien Mazarguil
6WIND
On Tue, Aug 09, 2016 at 02:47:44PM -0700, John Fastabend wrote:
> On 16-08-04 06:24 AM, Adrien Mazarguil wrote:
> > On Wed, Aug 03, 2016 at 12:11:56PM -0700, John Fastabend wrote:
[...]
> >> The problem is keeping priorities in order and/or possibly breaking
> >> rules
ricks hence my above suggestions.
All right, I agree a method to let applications precisely define what they
want to match can be useful now I understand what you mean by
"dynamically".
> Also in the current scheme how would I match an ipv6 option or specific
> nsh option or mpls tag?
Ideally through specific pattern items defined for this purpose, which is
how I thought the API would evolve. Of course it wouldn't be fully dynamic
and you'd have to wait for a DPDK release that implements them.
--
Adrien Mazarguil
6WIND
ine
> for use cases where I'm building a pipeline on top of the hardware.
Yes that's a possibility. Perhaps the table ID to use could be specified as
a meta pattern item? We'd still need methods to report how many tables exist
and perhaps some way to report their limitations, these could be later
through a separate set of functions.
[...]
> >>> For this adding a meta-data item seems simplest to me. And if you want
> >>> to make the default to be only a single port that would maybe make it
> >>> easier for existing apps to port from flow director. Then if an
> >>> application cares it can create a list of ports if needed.
> >>>
> >>
> >> Agreed.
> >
> > However although I'm not opposed to adding dedicated meta items, remember
> > applications will not automatically benefit from the increased performance
> > if a single PMD implements this feature, their maintainers will probably not
> > bother with it.
> >
>
> Unless as we noted in other thread the application is closely bound to
> its hardware for capability reasons. In this case it would make sense
> to implement.
Sure.
[...]
--
Adrien Mazarguil
6WIND
arate conversion layer.
> >>> I looked at the git repo but I only saw the header definition I guess
> >>> the implementation is TBD after there is enough agreement on the
> >>> interface?
> >
> > Precisely, I intend to update the tree and send a v2 soon (unfortunately did
> > not have much time these past few days to work on this).
> >
> > Now what if, instead of a seemingly complex parse graph and still in
> > addition to the query method, enum values were defined for PMDs to report
> > an array of supported items, typical patterns and actions so applications
> > can get a quick idea of what devices are capable of without being too
> > specific. Something like:
> >
> > enum rte_flow_capability {
> > RTE_FLOW_CAPABILITY_ITEM_ETH,
> > RTE_FLOW_CAPABILITY_PATTERN_ETH_IP_TCP,
> > RTE_FLOW_CAPABILITY_ACTION_ID,
> > ...
> > };
> >
> > Although I'm not convinced about the usefulness of this because it would
> > have to be maintained separately, but that would be easier than building a
> > dummy flow rule for simple query purposes.
>
> I'm not sure its necessary either at first.
Then I'll discard this idea.
> > The main question I have for you is, do you think the core of the specified
> > API is adequate enough assuming it can be extended later with new methods?
> >
>
> The above two items are my only opens at this point, I agree with your
> summary of my capabilities proposal namely it can be added.
Thanks, see you in the other thread.
--
Adrien Mazarguil
6WIND
> > On Thursday, July 07/21/16, 2016 at 19:07:38 +0200, Adrien Mazarguil
> > > wrote:
> > >> Hi Rahul,
> > >>
> > >> Please see below.
> > >>
> > >> On Thu, Jul 21, 2016 at 01:43:37PM +0530, Rahul Lakkireddy w
the MAC address of a VF after adding a conflicting
flow rule on a PF should not be allowed or remain undefined.
All of this is not described in the specification yet because PF/VF patterns
and actions are not fully defined at the moment, there is still some
uncertainty about them.
> I should reiterate that I think this will be a big improvement, so thank
> you for proposing it.
Thanks!
--
Adrien Mazarguil
6WIND
Hi John,
I'm replying below to both messages.
On Tue, Aug 02, 2016 at 11:19:15AM -0700, John Fastabend wrote:
> On 16-07-23 02:10 PM, John Fastabend wrote:
> > On 16-07-21 12:20 PM, Adrien Mazarguil wrote:
> >> Hi Jerin,
> >>
> >> Sorry, looks like I
gt; --
> 1.9.1
A few nit-picks from check-git-log.sh:
Wrong headline uppercase:
net/mlx5: Fix possible NULL deref in RX path
Wrong headline lowercase:
net/mlx5: Fix possible NULL deref in RX path
Missing blank line after 'Fixes' tag:
Fixes: a1bdb71a32da ("net/mlx5: fix crash in Rx")
Otherwise,
Acked-by: Adrien Mazarguil
--
Adrien Mazarguil
6WIND
On Tue, Aug 02, 2016 at 01:47:55PM +0300, Sagi Grimberg wrote:
>
>
> On 02/08/16 12:58, Adrien Mazarguil wrote:
> >On Tue, Aug 02, 2016 at 12:31:35PM +0300, Sagi Grimberg wrote:
> >>
> >>
> >>On 01/08/16 19:43, Adrien Mazarguil wrote:
> >>>
On Tue, Aug 02, 2016 at 12:31:35PM +0300, Sagi Grimberg wrote:
>
>
> On 01/08/16 19:43, Adrien Mazarguil wrote:
> >Hi Sagi,
> >
> >On Mon, Aug 01, 2016 at 11:44:21AM +0300, Sagi Grimberg wrote:
> >>The user is allowed to call ->rx_pkt_burst()
...
}
I guess you could add "Fixes: a1bdb71a32da ("net/mlx5: fix crash in Rx")"
line to your commit log as well because the original patch only solved half
of the issue.
Thanks.
--
Adrien Mazarguil
6WIND
v] [PATCH] doc: announce driver name changes
> >
> > On 7/22/2016 1:54 PM, Adrien Mazarguil wrote:
> > > Hi Pablo,
> > >
> > > On Fri, Jul 22, 2016 at 12:37:22PM +, De Lara Guarch, Pablo wrote:
> > >> Hi,
> > >>
> > >>
rt from Christian Ehrhardt's)?
Yes, since you're suggesting to prefix driver names, shall "librte_pmd_mlx5"
really become "net_librte_pmd_mlx5" or shortened to "net_mlx5" instead?
What about using a '/' separator instead of '_'?
Will this impact directories as well ("net/mlx5" -> "net/net_mlx5")?
--
Adrien Mazarguil
6WIND
Hi Jerin,
Sorry, looks like I missed your reply. Please see below.
On Mon, Jul 11, 2016 at 04:11:43PM +0530, Jerin Jacob wrote:
> On Tue, Jul 05, 2016 at 08:16:46PM +0200, Adrien Mazarguil wrote:
>
> Hi Adrien,
>
> Overall this proposal looks very good. I c
of flow rules in any order. If rules a/b/c can be created, then it won't
make sense from an application point of view if c/a/b for some reason cannot
and the PMD maintainers will rightfully get a bug report.
> More comments below.
>
> On Tuesday, July 07/05/16, 2016 at 20:16:46 +0200,
n the device globally so packets which are
not matched are not affected by RSS processing. As a result it might not be
possible to configure two flow rules specifying incompatible RSS actions
simultaneously if the underlying device supports only a single global RSS
context.
Are we on the same page?
--
Adrien Mazarguil
6WIND
of (patterns / actions) is maintained by
> > applications
> > (not RTE), and only if they need them. RTE would needlessly duplicate this.
> As said before, need more details to understand this. Maybe an example is
> better :)
The generic format both RTE and applications might understand is the one
described in this API (struct rte_flow_pattern and struct
rte_flow_actions).
If we wanted RTE to maintain some sort of per-port state for flow rule
specifications, it would have to be a copy of these structures arranged
somehow (list or something else).
If we consider that PMDs need to keep a context object associated to a flow
rule (the opaque struct rte_flow *), then RTE would most likely have to
store it along with the flow specification.
Such a list may not be useful to applications (list lookups take time), so
they would implement their own redundant method. They might also require
extra room to attach some application context to flow rules. A generic list
cannot plan for it.
Applications know what they want to do with flow rules and are responsible
for managing them efficiently with RTE out of the way.
I'm not sure if this answered your question, if not, please describe a
scenario where a RTE-managed list of flow rules would be mandatory.
--
Adrien Mazarguil
6WIND
d, rte can reconfigure the rules. Is the
> concern that PMD may adjust the sequence of the rules according to the
> priority, so every NIC has a different list of rules? But PMD can adjust them
> again when rte reconfiguring the rules.
What about PMDs able to stop and restart ports without destroying their own
flow rules? If we assume flow rules must be destroyed when stopping a port,
these PMDs are needlessly penalized with slower stop/start cycles. Think
about it assuming thousands of flow rules.
Thus from an application point of view, whatever happens when stopping and
restarting a port should not matter. If a flow rule was present before, it
must still be present afterwards. If the PMD had to destroy flow rules and
re-create them, it does not actually matter if they differ slightly at the
HW level, as long as:
- Existing opaque flow rule pointers (rte_flow) are still valid to the PMD
and refer to the same rules.
- The overall behavior of all rules is the same.
The list of rules you think of (patterns / actions) is maintained by
applications (not RTE), and only if they need them. RTE would needlessly
duplicate this.
--
Adrien Mazarguil
6WIND
of single bit ID but it could be
implemented through a different action for less capable devices. PMDs that
support 32 bit IDs could reuse the same code for both features.
I understand you'd prefer having this feature always present, however we
already know that not all PMDs/devices support it, and like everything else
this is a kind of offload that needs to be explicitly requested by the
application as it may not be needed.
If we go with the separate action, then perhaps it would make sense to
rename "ID" to "MARK" to make things clearer:
RTE_FLOW_ACTION_TYPE_FLAG /* Flag packets processed by flow rule. */
RTE_FLOW_ACTION_TYPE_MARK /* Attach a 32 bit value to a packet. */
I guess the result of the FLAG action would be something in ol_flag.
Thoughts?
> > I think applications have to implement SW fallbacks all the time, as even
> > some sort of guarantee on the flow rule processing time may not be enough
> > to avoid misdirected packets and related security issues.
> [Sugesh] Software fallback will be there always. However I am little bit
> confused on
> the way software going to identify the packets that are already hardware
> processed . I feel we need some
> notification in the packet itself, when a hardware rule hits. ID/flag/any
> other options?
Yeah I think so too, as long as it is optional because we cannot assume all
PMDs will support it.
> > Let's wait for applications to start using this API and then consider an
> > extra
> > set of asynchronous / real-time functions when the need arises. It should
> > not
> > impact the way rules are specified
> [Sugesh] Sure. I think the rule definition may not impact with this.
Thanks for your comments.
--
Adrien Mazarguil
6WIND
On Fri, Jul 15, 2016 at 10:03:02PM +0100, Bruce Richardson wrote:
> On Wed, Jul 13, 2016 at 03:02:37PM +0200, Adrien Mazarguil wrote:
> > DPDK uses GNU C language extensions in most of its code base. This is fine
> > for internal source files whose compilation flags are con
what happens outside of the DPDK
> > context, or PMDs must find a way to satisfy everyone. I'm not a fan of
> > locking
> > either but it would be nice if flow rules configuration could be attempted
> > on
> > different ports simultaneously without the risk of wrecking anything, so
> > that
> > applications do not need to care.
> >
> > Possible cases for a dual port device with global flow rule settings
> > affecting
> > both ports:
> >
> > 1) ports 1 & 2 are managed by DPDK: this is the easy case, a rule that needs
> >to alter a global setting necessary for an existing rule on any port is
> >not allowed (EEXIST). PMD must maintain a device context common to both
> >ports in order for this to work. This context is either under lock, or
> >the first port on which a flow rule is created owns all future flow
> >rules.
> >
> > 2) port 1 is managed by DPDK, port 2 by something else, the PMD is aware of
> >it and knows that port 2 may modify the global context: no flow rules can
> >be created from the DPDK application due to safety issues (EBUSY?).
> >
> > 3) port 1 is managed by DPDK, port 2 by something else, the PMD is aware of
> >it and knows that port 2 will not modify flow rules: PMD should not care,
> >no lock necessary.
> >
> > 4) port 1 is managed by DPDK, port 2 by something else and the PMD is not
> >aware of it: either flow rules cannot be created ever at all, or we say
> >it is user's reponsibility to make sure this does not happen.
> >
> > Considering that most control operations performed by DPDK affect the
> > device regardless of other applications, I think 1) is the only case that
> > should
> > be defined, otherwise 4), defined as user's responsibility.
No more comments on this part? What do you suggest?
--
Adrien Mazarguil
6WIND
ons performed by DPDK affect the device
regardless of other applications, I think 1) is the only case that should be
defined, otherwise 4), defined as user's responsibility.
> > > > Destruction
> > > > ~~~
> > > >
> > > > Flow rules destruction is not automatic, and a queue should not be
> > released
> > > > if any are still attached to it. Applications must take care of
> > > > performing
> > > > this step before releasing resources.
> > > >
> > > > ::
> > > >
> > > > int
> > > > rte_flow_destroy(uint8_t port_id,
> > > > struct rte_flow *flow);
> > > >
> > > >
> > > [Sugesh] I would suggest having a clean-up API is really useful as the
> > releasing of
> > > Queue(is it applicable for releasing of port too?) is not guaranteeing the
> > automatic flow
> > > destruction.
> >
> > Would something like rte_flow_flush(port_id) do the trick? I wanted to
> > emphasize in this first draft that applications should really keep the flow
> > pointers around in order to manage/destroy them. It is their responsibility,
> > not PMD's.
> [Sugesh] Thanks, I think the flush call will do.
Noted, will add it.
> > > This way application can initialize the port,
> > > clean-up all the existing rules and create new rules on a clean slate.
> >
> > No resource can be released as long as a flow rule is using it (bad things
> > may happen otherwise), all flow rules must be destroyed first, thus none can
> > possibly remain after initializing a port. It is assumed that PMDs do
> > automatic clean up during init if necessary to ensure this.
> [Sugesh] That will do.
I will make it more explicit as well.
[...]
--
Adrien Mazarguil
6WIND
plicit.
Signed-off-by: Olga Shern
Signed-off-by: Adrien Mazarguil
---
drivers/net/mlx5/mlx5_rxtx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 615de94..fce3381 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
This script checks that header files in a given directory do not miss
dependencies when included on their own, do not conflict and accept being
compiled with the strictest possible flags.
Signed-off-by: Adrien Mazarguil
---
MAINTAINERS | 1 +
scripts/check-includes.sh | 286
Arch-specific functions not defined for all architectures (missing on x86
in this case) and not used anywhere should not expose a prototype.
This commit prevents the following error:
error: `rte_mov48' declared `static' but never defined
Signed-off-by: Adrien Mazarguil
---
lib/librte_eal
__VA_ARGS__ with an extra dummy argument to format strings.
This commit prevents the following errors:
error: ISO C does not permit named variadic macros
Signed-off-by: Adrien Mazarguil
---
lib/librte_cryptodev/rte_cryptodev.h | 32 ++---
lib/librte_cryptodev
to `enum' types
Signed-off-by: Adrien Mazarguil
---
lib/librte_eal/common/include/generic/rte_cpuflags.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h
b/lib/librte_eal/common/include/generic/rte_cpuflags.h
index c1da357..71321f3 100644
1 - 100 of 486 matches
Mail list logo
