Re: [dpdk-dev] [PATCH] test: fix flow classifier creating failure
> -Original Message-
> From: Min Hu (Connor)
> Sent: Thursday, April 22, 2021 7:14 AM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Iremonger, Bernard
>
> Subject: [PATCH] test: fix flow classifier creating failure
>
> 'cls->cls' will be NULL if flow classifier create has failed, then
> segmentation
> fault will occur if the variable is used.
>
> This patch fixed it.
>
> Fixes: 9c9befea4f57 ("test: add flow classify unit tests")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Min Hu (Connor)
Acked-by: Bernard Iremonger
Re: [dpdk-dev] [PATCH 1/3] examples/flow_classify: fix check of port and core
Hi Min,
> -Original Message-
> From: Thomas Monjalon
> Sent: Tuesday, April 20, 2021 10:41 AM
> To: Min Hu (Connor)
> Cc: dev@dpdk.org; Yigit, Ferruh ; Iremonger,
> Bernard ; Kantecki, Tomasz
> ; Richardson, Bruce
> ; Burakov, Anatoly
> ; david.march...@redhat.com
> Subject: Re: [dpdk-dev] [PATCH 1/3] examples/flow_classify: fix check of
> port and core
>
> 20/04/2021 04:26, Min Hu (Connor):
> > 2021/4/20 9:08, Thomas Monjalon:
> > > 27/03/2021 08:40, Min Hu (Connor):
> > >> fix check of port and core in flow_classify example.
> > >>
> > >> Fixes: bab16ddaf2c1 ("examples/flow_classify: add sample
> > >> application")
> > >> Cc: sta...@dpdk.org
> > >>
> > >> Signed-off-by: Min Hu (Connor)
> > >> ---
> > >> RTE_ETH_FOREACH_DEV(port)
> > >> -if (rte_eth_dev_socket_id(port) > 0 &&
> > >> +if (rte_eth_dev_socket_id(port) >= 0 &&
This fix works (I have tested it on my system)
However a cleaner fix would be to drop the above line and add the if on the
next line instead (also tested on my system).
If (rte_eth_dev_socket_id(port) != (int)rte_socket_id())
> > >> rte_eth_dev_socket_id(port) !=
> > >> (int)rte_socket_id())
> {
> > >> printf("\n\n");
> > >> printf("WARNING: port %u is on remote NUMA
> node\n",
> > >
> > > Please explain which case is broken and why.
> > > If I understand well, we don't detect remote NUMA if not running on first
> socket.
> > >
> > Hi, the code is this:
> >
> **
> ***
> > /*
> > * Check that the port is on the same NUMA node as the polling
> thread
> > * for best performance.
> > */
> > RTE_ETH_FOREACH_DEV(port)
> > if (rte_eth_dev_socket_id(port) > 0 &&
> > rte_eth_dev_socket_id(port) != (int)rte_socket_id())
> {
> > printf("\n\n");
> > printf("WARNING: port %u is on remote NUMA
> node\n",
> >port);
> > printf("to polling thread.\n");
> > printf("Performance will not be optimal.\n");
> > }
> > printf("\nCore %u forwarding packets. ", rte_lcore_id());
> > printf("[Ctrl+C to quit]\n");
> >
> **
>
> > ***
> >
> > According to the comments and logging, the author just hope user to
> > use the core and device which are in the same numa node for optimal
> > performance. If not, A warning gives out.
> >
> > For example in flow_classify:
> > ./build/flow_classify -w :7d:00.1 -l 93
> > Here:
> > :7d:00.1 is on numa node 0.
> > core 93 is on numa node 3.
> >
> > the two are not in same numa node, but no warning gives out in old codes.
> >
> > Well, using this patch, we can get the waring.
>
> You need to explain which case was broken in the commit log.
> Thanks
>
>
Regards,
Bernard.
Re: [dpdk-dev] [PATCH 1/3] examples/flow_classify: fix check of port and core
Hi Min,
> -Original Message-
> From: Min Hu (Connor)
> Sent: Tuesday, April 27, 2021 1:23 PM
> To: Iremonger, Bernard ; Thomas Monjalon
>
> Cc: dev@dpdk.org; Yigit, Ferruh ; Kantecki, Tomasz
> ; Richardson, Bruce
> ; Burakov, Anatoly
> ; david.march...@redhat.com
> Subject: Re: [dpdk-dev] [PATCH 1/3] examples/flow_classify: fix check of
> port and core
>
>
>
> 在 2021/4/27 19:51, Iremonger, Bernard 写道:
> > Hi Min,
> >
> >> -Original Message-
> >> From: Thomas Monjalon
> >> Sent: Tuesday, April 20, 2021 10:41 AM
> >> To: Min Hu (Connor)
> >> Cc: dev@dpdk.org; Yigit, Ferruh ; Iremonger,
> >> Bernard ; Kantecki, Tomasz
> >> ; Richardson, Bruce
> >> ; Burakov, Anatoly
> >> ; david.march...@redhat.com
> >> Subject: Re: [dpdk-dev] [PATCH 1/3] examples/flow_classify: fix check
> >> of port and core
> >>
> >> 20/04/2021 04:26, Min Hu (Connor):
> >>> 2021/4/20 9:08, Thomas Monjalon:
> >>>> 27/03/2021 08:40, Min Hu (Connor):
> >>>>> fix check of port and core in flow_classify example.
> >>>>>
> >>>>> Fixes: bab16ddaf2c1 ("examples/flow_classify: add sample
> >>>>> application")
> >>>>> Cc: sta...@dpdk.org
> >>>>>
> >>>>> Signed-off-by: Min Hu (Connor)
> >>>>> ---
> >>>>> RTE_ETH_FOREACH_DEV(port)
> >>>>> - if (rte_eth_dev_socket_id(port) > 0 &&
> >>>>> + if (rte_eth_dev_socket_id(port) >= 0 &&
> >
> > This fix works (I have tested it on my system) However a cleaner fix
> > would be to drop the above line and add the if on the next line instead
> (also tested on my system).
> >
> Hi, 'rte_eth_dev_socket_id(port)' may return -1, we should avoid this
> situation.
Agreed.
Original fix is good.
>
> > If (rte_eth_dev_socket_id(port) != (int)rte_socket_id())
> >
> >>>>> rte_eth_dev_socket_id(port) !=
> (int)rte_socket_id())
> >> {
> >>>>> printf("\n\n");
> >>>>> printf("WARNING: port %u is on remote
> NUMA
> >> node\n",
> >>>>
> >>>> Please explain which case is broken and why.
> >>>> If I understand well, we don't detect remote NUMA if not running on
> >>>> first
> >> socket.
> >>>>
> >>> Hi, the code is this:
> >>>
> >>
> **
> >> ***
> >>> /*
> >>>* Check that the port is on the same NUMA node as the polling
> >> thread
> >>>* for best performance.
> >>>*/
> >>> RTE_ETH_FOREACH_DEV(port)
> >>> if (rte_eth_dev_socket_id(port) > 0 &&
> >>> rte_eth_dev_socket_id(port) != (int)rte_socket_id())
> >> {
> >>> printf("\n\n");
> >>> printf("WARNING: port %u is on remote NUMA
> >> node\n",
> >>> port);
> >>> printf("to polling thread.\n");
> >>> printf("Performance will not be optimal.\n");
> >>> }
> >>> printf("\nCore %u forwarding packets. ", rte_lcore_id());
> >>> printf("[Ctrl+C to quit]\n");
> >>>
> >>
> **
> >>
> >>> ***
> >>>
> >>> According to the comments and logging, the author just hope user to
> >>> use the core and device which are in the same numa node for optimal
> >>> performance. If not, A warning gives out.
> >>>
> >>> For example in flow_classify:
> >>> ./build/flow_classify -w :7d:00.1 -l 93
> >>> Here:
> >>> :7d:00.1 is on numa node 0.
> >>> core 93 is on numa node 3.
> >>>
> >>> the two are not in same numa node, but no warning gives out in old
> codes.
> >>>
> >>> Well, using this patch, we can get the waring.
> >>
> >> You need to explain which case was broken in the commit log.
> >> Thanks
> >>
> >>
> > Regards,
> >
> > Bernard.
> > .
> >
Regards,
Bernard.
Re: [dpdk-dev] [PATCH 1/3] examples/flow_classify: fix check of port and core
Hi Min, > > >>> > > >>> According to the comments and logging, the author just hope user > > >>> to use the core and device which are in the same numa node for > > >>> optimal performance. If not, A warning gives out. > > >>> > > >>> For example in flow_classify: > > >>> ./build/flow_classify -w :7d:00.1 -l 93 The EAL option "-w" has been replaced by the "-a" option in dpdk-20.05 > > >>> Here: > > >>> :7d:00.1 is on numa node 0. > > >>> core 93 is on numa node 3. > > >>> > > >>> the two are not in same numa node, but no warning gives out in old > > codes. > > >>> > > >>> Well, using this patch, we can get the waring. > > >> > > >> You need to explain which case was broken in the commit log. > > >> Thanks Regards, Bernard.
Re: [dpdk-dev] [PATCH v2 1/3] examples/flow_classify: fix check of port and core
Hi Min,
> -Original Message-
> From: Min Hu (Connor)
> Sent: Wednesday, April 21, 2021 8:00 AM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Iremonger, Bernard
> ; Kantecki, Tomasz
> ; Richardson, Bruce
> ; tho...@monjalon.net
> Subject: [PATCH v2 1/3] examples/flow_classify: fix check of port and core
>
> According to the comments and logging, the author just hope user to use the
> core and device which are in the same numa node for optimal performance.
> If not, A warning gives out.
>
> For example in flow_classify:
> ./build/flow_classify -w :7d:00.1 -l 93
The EAL option "-w" has been replaced by the "-a" option in dpdk-20.05
> Here:
> :7d:00.1 is on numa node 0.
> core 93 is on numa node 3.
>
> The two are not in same numa node, but no warning gives out in old codes.
>
> This patch can fix it.
>
> Fixes: bab16ddaf2c1 ("examples/flow_classify: add sample application")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Min Hu (Connor)
> ---
> examples/flow_classify/flow_classify.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/examples/flow_classify/flow_classify.c
> b/examples/flow_classify/flow_classify.c
> index 335d7d2..277a2f5 100644
> --- a/examples/flow_classify/flow_classify.c
> +++ b/examples/flow_classify/flow_classify.c
> @@ -284,7 +284,7 @@ lcore_main(struct flow_classifier *cls_app)
>* for best performance.
>*/
> RTE_ETH_FOREACH_DEV(port)
> - if (rte_eth_dev_socket_id(port) > 0 &&
> + if (rte_eth_dev_socket_id(port) >= 0 &&
> rte_eth_dev_socket_id(port) != (int)rte_socket_id())
> {
> printf("\n\n");
> printf("WARNING: port %u is on remote NUMA
> node\n",
> --
> 2.7.4
Tested-by: Bernard Iremonger
Re: [dpdk-dev] [PATCH v3 1/3] examples/flow_classify: fix check of port and core
> -Original Message-
> From: Min Hu (Connor)
> Sent: Thursday, April 29, 2021 1:51 AM
> To: dev@dpdk.org
> Cc: Yigit, Ferruh ; Iremonger, Bernard
> ; tho...@monjalon.net
> Subject: [PATCH v3 1/3] examples/flow_classify: fix check of port and core
>
> According to the comments and logging, the author just hope user to use the
> core and device which are in the same numa node for optimal performance.
> If not, A warning gives out.
>
> For example in flow_classify:
> ./build/flow_classify -a :7d:00.1 -l 93
> Here:
> :7d:00.1 is on numa node 0.
> core 93 is on numa node 3.
>
> The two are not in same numa node, but no warning gives out in old codes.
>
> This patch can fix it.
>
> Fixes: bab16ddaf2c1 ("examples/flow_classify: add sample application")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Min Hu (Connor)
Tested-by: Bernard Iremonger
Acked-by: Bernard Iremonger
Re: [dpdk-dev] [PATCH] lib/flow_classify: fix leaking rules on delete
Hi David, Owen,
> -Original Message-
> From: David Marchand
> Sent: Tuesday, June 22, 2021 8:24 AM
> To: Owen Hilyard ; Iremonger, Bernard
> ; Yigit, Ferruh
> Cc: dev
> Subject: Re: [PATCH] lib/flow_classify: fix leaking rules on delete
>
> On Wed, Jun 16, 2021 at 9:57 PM wrote:
> >
> > From: Owen Hilyard
> >
> > Rules in a classify table were not freed if the table had a delete
> > function.
> >
> > Fixes: be41ac2a3 ("flow_classify: introduce flow classify library")
> Cc: sta...@dpdk.org
>
> >
> > Signed-off-by: Owen Hilyard
> > ---
> > lib/flow_classify/rte_flow_classify.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/flow_classify/rte_flow_classify.c
> > b/lib/flow_classify/rte_flow_classify.c
> > index f125267e8..06aed3b70 100644
> > --- a/lib/flow_classify/rte_flow_classify.c
> > +++ b/lib/flow_classify/rte_flow_classify.c
> > @@ -579,7 +579,7 @@ rte_flow_classify_table_entry_delete(struct
> rte_flow_classifier *cls,
> > &rule->u.key.key_del,
> > &rule->key_found,
> > &rule->entry);
> > -
> > + free(rule);
> > return ret;
> > }
> > }
>
> I find it strange to free the rule regardless of the result of the
> f_delete() op.
I agree the result of the f_delete() op should be checked before freeing the
rule.
> The same is done out of the loop which means this function returns -EINVAL
> and frees the rule in this case too.
The free() outside the loop at line 587 does not make sense to me now and
should be removed.
>
> Bernard, Ferruh, can you review please?
>
> Thanks!
>
>
> --
> David Marchand
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v2] flow_classify: fix leaking rules on delete
Hi Owen,
> -Original Message-
> From: ohily...@iol.unh.edu
> Sent: Wednesday, June 23, 2021 6:07 PM
> To: Iremonger, Bernard
> Cc: dev@dpdk.org; david.march...@redhat.com; Owen Hilyard
>
> Subject: [PATCH v2] flow_classify: fix leaking rules on delete
>
> From: Owen Hilyard
>
> Rules in a classify table were not freed if the table had a delete function.
>
> Fixes: be41ac2a3 ("flow_classify: introduce flow classify library")
>
> Signed-off-by: Owen Hilyard
> ---
> lib/flow_classify/rte_flow_classify.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/flow_classify/rte_flow_classify.c
> b/lib/flow_classify/rte_flow_classify.c
> index f125267e8..d3ba2ed22 100644
> --- a/lib/flow_classify/rte_flow_classify.c
> +++ b/lib/flow_classify/rte_flow_classify.c
> @@ -579,12 +579,12 @@ rte_flow_classify_table_entry_delete(struct
> rte_flow_classifier *cls,
> &rule->u.key.key_del,
> &rule->key_found,
> &rule->entry);
> -
> + if (ret == 0)
> + free(rule);
> return ret;
> }
> }
> }
> - free(rule);
> return ret;
> }
>
> --
> 2.30.2
This patch should be backported.
Please add the following line after the Fixes line:
Cc: sta...@dpdk.org
Otherwise
Acked-by: Bernard Iremonger
Re: [dpdk-dev] [PATCH v1 1/1] doc: clarify vfio doc for built-in modules
Hi Anatoly, > -Original Message- > From: dev On Behalf Of Anatoly Burakov > Sent: Thursday, October 14, 2021 1:53 PM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH v1 1/1] doc: clarify vfio doc for built-in modules > > Currently, the documentation only contains instructions for enabling SRIOV > support for VFIO compiled as a module, but doesn't have any instructions on > how to do the same for cases where VFIO is built-in. > Add these instructions. > > Signed-off-by: Anatoly Burakov > --- > doc/guides/linux_gsg/linux_drivers.rst | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/doc/guides/linux_gsg/linux_drivers.rst > b/doc/guides/linux_gsg/linux_drivers.rst > index c6b6881ea2..2dd711bb37 100644 > --- a/doc/guides/linux_gsg/linux_drivers.rst > +++ b/doc/guides/linux_gsg/linux_drivers.rst > @@ -65,6 +65,12 @@ The token will be used for all PF and VF ports within > the application. > >sudo modprobe vfio-pci enable_sriov=1 > > + Alternatively, pass the ``enable_sriov`` parameter through the ``sysfs`` > if > the module is already loaded or is built-in: Probably better to wrap above line as quite long. > + > + .. code-block:: console > + > + echo 1 | sudo tee /sys/module/vfio_pci/parameters/enable_sriov > + > #. Bind the PCI devices to ``vfio-pci`` driver > > .. code-block:: console > -- > 2.25.1 ~/dpdk_21_11/devtools# ./check-git-log.sh Wrong headline case: "doc: clarify vfio doc for built-in modules": vfio --> VFIO Invalid patch(es) found - checked 1 patch Otherwise Acked-by: Bernard Iremonger
Re: [dpdk-dev] [PATCH] flow_classify: remove eperimental tag from the API
Hi Kevin,
> -Original Message-
> From: Kevin Traynor
> Sent: Wednesday, September 22, 2021 3:48 PM
> To: Iremonger, Bernard ; Kinsella, Ray
> ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] flow_classify: remove eperimental tag from
> the API
>
> s/eperimental/experimental/
>
> On 15/09/2021 16:16, Bernard Iremonger wrote:
> > This API was introduced in 17.11, removing experimental tag to promote
> > to stable state.
> >
> > Signed-off-by: Bernard Iremonger
> > ---
> > lib/flow_classify/rte_flow_classify.h | 7 ---
> > lib/flow_classify/version.map | 2 +-
> > 2 files changed, 1 insertion(+), 8 deletions(-)
> >
>
> The library is still listed as experimental
> https://git.dpdk.org/dpdk/tree/lib/flow_classify/rte_flow_classify.h#n13
>
> and you can remove the allow_experimental_apis from the example app
> now.
Good catch.
I will remove allow_experimental_apis from the flow_classify/meson.build file.
> > diff --git a/lib/flow_classify/rte_flow_classify.h
> > b/lib/flow_classify/rte_flow_classify.h
> > index 82ea92b6a6..3759cd32af 100644
> > --- a/lib/flow_classify/rte_flow_classify.h
> > +++ b/lib/flow_classify/rte_flow_classify.h
> > @@ -157,7 +157,6 @@ struct rte_flow_classify_ipv4_5tuple_stats {
> >* @return
> >* Handle to flow classifier instance on success or NULL otherwise
> >*/
> > -__rte_experimental
> > struct rte_flow_classifier *
> > rte_flow_classifier_create(struct rte_flow_classifier_params
> > *params);
> >
> > @@ -169,7 +168,6 @@ rte_flow_classifier_create(struct
> rte_flow_classifier_params *params);
> >* @return
> >* 0 on success, error code otherwise
> >*/
> > -__rte_experimental
> > int
> > rte_flow_classifier_free(struct rte_flow_classifier *cls);
> >
> > @@ -183,7 +181,6 @@ rte_flow_classifier_free(struct rte_flow_classifier
> *cls);
> >* @return
> >* 0 on success, error code otherwise
> >*/
> > -__rte_experimental
> > int
> > rte_flow_classify_table_create(struct rte_flow_classifier *cls,
> > struct rte_flow_classify_table_params *params); @@ -205,7
> +202,6
> > @@ rte_flow_classify_table_create(struct rte_flow_classifier *cls,
> >* @return
> >* 0 on success, error code otherwise
> >*/
> > -__rte_experimental
> > int
> > rte_flow_classify_validate(struct rte_flow_classifier *cls,
> > const struct rte_flow_attr *attr,
> > @@ -232,7 +228,6 @@ rte_flow_classify_validate(struct rte_flow_classifier
> *cls,
> >* @return
> >* A valid handle in case of success, NULL otherwise.
> >*/
> > -__rte_experimental
> > struct rte_flow_classify_rule *
> > rte_flow_classify_table_entry_add(struct rte_flow_classifier *cls,
> > const struct rte_flow_attr *attr,
> > @@ -251,7 +246,6 @@ rte_flow_classify_table_entry_add(struct
> rte_flow_classifier *cls,
> >* @return
> >* 0 on success, error code otherwise.
> >*/
> > -__rte_experimental
> > int
> > rte_flow_classify_table_entry_delete(struct rte_flow_classifier *cls,
> > struct rte_flow_classify_rule *rule); @@ -273,7 +267,6 @@
> > rte_flow_classify_table_entry_delete(struct rte_flow_classifier *cls,
> >* @return
> >* 0 on success, error code otherwise.
> >*/
> > -__rte_experimental
> > int
> > rte_flow_classifier_query(struct rte_flow_classifier *cls,
> > struct rte_mbuf **pkts,
> > diff --git a/lib/flow_classify/version.map
> > b/lib/flow_classify/version.map index 49bc25c6a0..b7a888053b 100644
> > --- a/lib/flow_classify/version.map
> > +++ b/lib/flow_classify/version.map
> > @@ -1,4 +1,4 @@
> > -EXPERIMENTAL {
> > +DPDK_22 {
> > global:
> >
> > rte_flow_classifier_create;
> >
Regards,
Bernard.
Re: [dpdk-dev] [PATCH 1/2] Hooks to allow the setting of filters on tcp flags
Hi Sowmini,
> -Original Message-
> From: Sowmini Varadhan
> Sent: Thursday, August 12, 2021 9:18 PM
> To: sowmin...@gmail.com; Iremonger, Bernard
> ; dev@dpdk.org;
> sovar...@linux.microsoft.com
> Cc: tho...@monjalon.net
> Subject: [PATCH 1/2] Hooks to allow the setting of filters on tcp flags
~/dpdk_21_08/devtools# ./check-git-log.sh -1
Wrong headline format:
Hooks to allow the setting of filters on tcp flags
The subject line should be prefixed with examples/flow_classify:
examples/flow_classify: Hooks to allow the setting of filters on tcp flags
>
> The rte_eth_ntuple_filter allows tcp_flags which can check for things like
> #define RTE_TCP_CWR_FLAG 0x80 /**< Congestion Window Reduced */
> #define RTE_TCP_ECE_FLAG 0x40 /**< ECN-Echo */
> #define RTE_TCP_URG_FLAG 0x20 /**< Urgent Pointer field significant */
> #define RTE_TCP_ACK_FLAG 0x10 /**< Acknowledgment field significant
> */
> #define RTE_TCP_PSH_FLAG 0x08 /**< Push Function */
> #define RTE_TCP_RST_FLAG 0x04 /**< Reset the connection */
> #define RTE_TCP_SYN_FLAG 0x02 /**< Synchronize sequence numbers */
> #define RTE_TCP_FIN_FLAG 0x01 /**< No more data from sender */ but
> there are no existing examples that demonstrate how to use this feature.
>
> This patch extends the exisiting classification support to allow an optional
Typo: " exisiting" should be "existing"
> flags in the input file. The flags string can be any concatenation of
> characters
> from {C, E, U, A, P, R, S, F} and "*" indicates "dont care". These flags are
> set in
> the ntuple_filter and are used to construct the tcp_spec and tcp_mask sent
> to the driver
>
> The rte_acl_field_def is updated to use the (u8) tcp flag as lookup key.
> Note that, as per
> https://doc.dpdk.org/guides/prog_guide/packet_classif_access_ctrl.html
> this field MUST be allocated fo4 4 bytes, thus it has sizeof(uint32_t).
Typo: "fo4" should be "for"
>
> However, also note the XXX in this commit: additional updates are needed to
> the rte_flow_classify_table_entry_add() so that it does not ignore any key
> fields other than the 5-tuple.
>
> Signed-off-by: Sowmini Varadhan
> ---
> examples/flow_classify/flow_classify.c | 87 --
> examples/flow_classify/ipv4_rules_file.txt | 22 +++---
> 2 files changed, 91 insertions(+), 18 deletions(-)
>
> diff --git a/examples/flow_classify/flow_classify.c
> b/examples/flow_classify/flow_classify.c
> index db71f5aa04..772b15adf2 100644
> --- a/examples/flow_classify/flow_classify.c
> +++ b/examples/flow_classify/flow_classify.c
> @@ -51,6 +51,7 @@ enum {
> CB_FLD_DST_PORT_MASK,
> CB_FLD_PROTO,
> CB_FLD_PRIORITY,
> + CB_FLD_TCP_FLAGS,
> CB_FLD_NUM,
> };
>
> @@ -86,6 +87,7 @@ enum {
> DST_FIELD_IPV4,
> SRCP_FIELD_IPV4,
> DSTP_FIELD_IPV4,
> + TCP_FLAGS_FIELD,
> NUM_FIELDS_IPV4
> };
>
> @@ -93,7 +95,8 @@ enum {
> PROTO_INPUT_IPV4,
> SRC_INPUT_IPV4,
> DST_INPUT_IPV4,
> - SRCP_DESTP_INPUT_IPV4
> + SRCP_DESTP_INPUT_IPV4,
> + TCP_FLAGS_INDEX,
> };
>
> static struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = { @@ -150,6
> +153,17 @@ static struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
> sizeof(struct rte_ipv4_hdr) +
> offsetof(struct rte_tcp_hdr, dst_port),
> },
> + /* next field must be 4 bytes, even though flags is only 1 byte */
> + {
> + /* rte_flags */
> + .type = RTE_ACL_FIELD_TYPE_BITMASK,
> + .size = sizeof(uint32_t),
> + .field_index = TCP_FLAGS_FIELD,
> + .input_index = TCP_FLAGS_INDEX,
> + .offset = sizeof(struct rte_ether_hdr) +
> + sizeof(struct rte_ipv4_hdr) +
> + offsetof(struct rte_tcp_hdr, tcp_flags),
> + },
> };
> /* >8 End of creation of ACL table. */
>
> @@ -285,12 +299,14 @@ lcore_main(struct flow_classifier *cls_app)
> int ret;
> int i = 0;
>
> - ret = rte_flow_classify_table_entry_delete(cls_app->cls,
> - rules[7]);
> - if (ret)
> - printf("table_entry_delete failed [7] %d\n\n", ret);
> - else
> - printf("table_entry_delete succeeded [7]\n\n");
> + if (rules[7]) {
> + ret = rte_flow_classify_table_entry_delete(cls_app->cls,
> + rules[7]);
> + if (ret)
> + printf("table_entry_delete failed [7] %d\n\n"
Re: [dpdk-dev] [PATCH 2/2] Allow the flow_classify example to add an ACL table for tcp.
Hi Sowmini,
> -Original Message-
> From: Sowmini Varadhan
> Sent: Thursday, August 12, 2021 9:18 PM
> To: sowmin...@gmail.com; Iremonger, Bernard
> ; dev@dpdk.org; sowmi...@gmail.com;
> sovar...@linux.microsoft.com
> Cc: tho...@monjalon.net
> Subject: [PATCH 2/2] Allow the flow_classify example to add an ACL table for
> tcp.
./check-git-log.sh -1
Wrong headline format:
Allow the flow_classify example to add an ACL table for tcp.
The subject line should be prefixed with examples/flow_classify:
flow_classify: Allow the flow_classify example to add an ACL table for tcp
>
> The struct rte_flow_classifier can have upto
> RTE_FLOW_CLASSIFY_TABLE_MAX
> (32) classifier tables, but the existing flow_classify examples only adds a
> single table for the L4 5-tuple.
>
> When dealing with tcp flows, we frequently want to add add ACLs and filters
> to filter based on the state of the TCP connection, e.g., by looking at the
> tcp
> flags field.
>
> So we enhance flow_classify to add an additional acl table for tcp 5-typles.
> If
> the input-file-parser detects a filter for a tcp flow with a non-wildcard
> argument for tcp_flags, the IP4_TCP_5TUPLE table is used by flow_classify.
>
> Signed-off-by: Sowmini Varadhan
> ---
> examples/flow_classify/flow_classify.c | 41 +++---
> lib/flow_classify/rte_flow_classify.c | 87 +
> lib/flow_classify/rte_flow_classify.h | 19 +
> lib/flow_classify/rte_flow_classify_parse.c | 8 +-
> 4 files changed, 142 insertions(+), 13 deletions(-)
>
> diff --git a/examples/flow_classify/flow_classify.c
> b/examples/flow_classify/flow_classify.c
> index 772b15adf2..b42d0df5c3 100644
> --- a/examples/flow_classify/flow_classify.c
> +++ b/examples/flow_classify/flow_classify.c
> @@ -723,11 +723,6 @@ add_classify_rule(struct rte_eth_ntuple_filter
> *ntuple_filter,
> return ret;
> }
>
> - /* XXX but this only adds table_type of
> - * RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_5TUPLE
> - * i.e., it only ever does allocate_acl_ipv4_5tuple_rule()
> - * so the tcp_flags is ignored!
> - */
> rule = rte_flow_classify_table_entry_add(
> cls_app->cls, &attr, pattern_ipv4_5tuple,
> actions, &key_found, &error);
> @@ -856,7 +851,8 @@ main(int argc, char *argv[])
> int ret;
> int socket_id;
> struct rte_table_acl_params table_acl_params;
> - struct rte_flow_classify_table_params cls_table_params;
> + struct rte_table_acl_params table_acl_tcp_params;
> + struct rte_flow_classify_table_params cls_table_params[2];
> struct flow_classifier *cls_app;
> struct rte_flow_classifier_params cls_params;
> uint32_t size;
> @@ -923,21 +919,42 @@ main(int argc, char *argv[])
> memcpy(table_acl_params.field_format, ipv4_defs,
> sizeof(ipv4_defs));
>
> /* initialise table create params */
> - cls_table_params.ops = &rte_table_acl_ops;
> - cls_table_params.arg_create = &table_acl_params;
> - cls_table_params.type =
> RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_5TUPLE;
> + cls_table_params[0].ops = &rte_table_acl_ops;
> + cls_table_params[0].arg_create = &table_acl_params;
> + cls_table_params[0].type =
> RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_5TUPLE;
> +
> + /* initialise ACL table params */
> + table_acl_tcp_params.name = "table_acl_ipv4_tcp_5tuple";
> + table_acl_tcp_params.n_rules = FLOW_CLASSIFY_MAX_RULE_NUM;
> + table_acl_tcp_params.n_rule_fields = RTE_DIM(ipv4_defs);
> + memcpy(table_acl_tcp_params.field_format, ipv4_defs,
> +sizeof(ipv4_defs));
> +
> + /* initialise table create params */
> + cls_table_params[1].ops = &rte_table_acl_ops;
> + cls_table_params[1].arg_create = &table_acl_tcp_params;
> + cls_table_params[1].type =
> RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_TCP_5TUPLE;
>
> - ret = rte_flow_classify_table_create(cls_app->cls,
> &cls_table_params);
> + ret = rte_flow_classify_table_create(cls_app->cls,
> + &cls_table_params[0]);
> if (ret) {
> rte_flow_classifier_free(cls_app->cls);
> rte_free(cls_app);
> rte_exit(EXIT_FAILURE, "Failed to create classifier table\n");
> }
> + ret = rte_flow_classify_table_create(cls_app->cls,
> + &cls_table_params[1]);
> + if (ret) {
> + rte_flow_classifier_free(cls_app->cls);
> + rte_free(cls_app);
> + rte_exit(EXIT_FAILURE,
> +
Re: [dpdk-dev] [PATCH v2 2/2] examples/flow_classify: add an ACL table for tcp
Hi Sowmini,
> -Original Message-
> From: Sowmini Varadhan
> Sent: Wednesday, August 18, 2021 4:01 PM
> To: sowmin...@gmail.com; Iremonger, Bernard
> ; dev@dpdk.org;
> sovar...@linux.microsoft.com
> Cc: tho...@monjalon.net
> Subject: [PATCH v2 2/2] examples/flow_classify: add an ACL table for tcp
>
> v2 updates: typo fixes for checkpatch, bernard.iremonger comments
The above line should not be added to the commit message.
~/dpdk/devtools/check-git-log.sh -1
Wrong tag:
v2 fixes: typo fixes, get_tcp_flags returns -EINVAL
The check-git-log.sh script is in your dpdk checkout, best to run this script
before sending patches
>
> The struct rte_flow_classifier can have up to
> RTE_FLOW_CLASSIFY_TABLE_MAX
> (32) classifier tables, but the existing flow_classify examples only adds a
> single table for the L4 5-tuple.
>
> When dealing with tcp flows, we frequently want to add ACLs and filters to
> filter based on the state of the TCP connection, e.g., by looking at the tcp
> flags field.
>
> So we enhance flow_classify to add an additional acl table for tcp 5-tuples.
> If
> the input-file-parser detects a filter for a tcp flow with a non-wildcard
> argument for tcp_flags, the IP4_TCP_5TUPLE table is used by flow_classify.
>
> Signed-off-by: Sowmini Varadhan
> ---
If you want comment on the patch updates (optional), it can be added here after
the --- line
> examples/flow_classify/flow_classify.c | 41 +++---
> lib/flow_classify/rte_flow_classify.c | 87 +
> lib/flow_classify/rte_flow_classify.h | 19 +
> lib/flow_classify/rte_flow_classify_parse.c | 8 +-
> 4 files changed, 142 insertions(+), 13 deletions(-)
This patch contains changes to the flow_classify example and the flow_classify
library.
It needs to be split in two, a patch for the flow_classify example and a patch
for the flow classify library.
>
> diff --git a/examples/flow_classify/flow_classify.c
> b/examples/flow_classify/flow_classify.c
> index ff4c8bc2f5..8f6aacae03 100644
> --- a/examples/flow_classify/flow_classify.c
> +++ b/examples/flow_classify/flow_classify.c
> @@ -723,11 +723,6 @@ add_classify_rule(struct rte_eth_ntuple_filter
> *ntuple_filter,
> return ret;
> }
>
> - /* XXX but this only adds table_type of
> - * RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_5TUPLE
> - * i.e., it only ever does allocate_acl_ipv4_5tuple_rule()
> - * so the tcp_flags is ignored!
> - */
> rule = rte_flow_classify_table_entry_add(
> cls_app->cls, &attr, pattern_ipv4_5tuple,
> actions, &key_found, &error);
> @@ -856,7 +851,8 @@ main(int argc, char *argv[])
> int ret;
> int socket_id;
> struct rte_table_acl_params table_acl_params;
> - struct rte_flow_classify_table_params cls_table_params;
> + struct rte_table_acl_params table_acl_tcp_params;
> + struct rte_flow_classify_table_params cls_table_params[2];
> struct flow_classifier *cls_app;
> struct rte_flow_classifier_params cls_params;
> uint32_t size;
> @@ -923,21 +919,42 @@ main(int argc, char *argv[])
> memcpy(table_acl_params.field_format, ipv4_defs,
> sizeof(ipv4_defs));
>
> /* initialise table create params */
> - cls_table_params.ops = &rte_table_acl_ops;
> - cls_table_params.arg_create = &table_acl_params;
> - cls_table_params.type =
> RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_5TUPLE;
> + cls_table_params[0].ops = &rte_table_acl_ops;
> + cls_table_params[0].arg_create = &table_acl_params;
> + cls_table_params[0].type =
> RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_5TUPLE;
> +
> + /* initialise ACL table params */
> + table_acl_tcp_params.name = "table_acl_ipv4_tcp_5tuple";
> + table_acl_tcp_params.n_rules = FLOW_CLASSIFY_MAX_RULE_NUM;
> + table_acl_tcp_params.n_rule_fields = RTE_DIM(ipv4_defs);
> + memcpy(table_acl_tcp_params.field_format, ipv4_defs,
> +sizeof(ipv4_defs));
> +
> + /* initialise table create params */
> + cls_table_params[1].ops = &rte_table_acl_ops;
> + cls_table_params[1].arg_create = &table_acl_tcp_params;
> + cls_table_params[1].type =
> RTE_FLOW_CLASSIFY_TABLE_ACL_IP4_TCP_5TUPLE;
>
> - ret = rte_flow_classify_table_create(cls_app->cls,
> &cls_table_params);
> + ret = rte_flow_classify_table_create(cls_app->cls,
> + &cls_table_params[0]);
> if (ret) {
> rte_flow_classifier_free(cls_app->cls);
> rte_free(cls_app);
> rte_exit(EXIT_FAILURE, "Failed to create classifier
Re: [dpdk-dev] [PATCH v2 1/2] examples/flow_classify: hooks for filters on tcp flags
HI Sowmini,
> -Original Message-
> From: Sowmini Varadhan
> Sent: Wednesday, August 18, 2021 4:01 PM
> To: sowmin...@gmail.com; Iremonger, Bernard
> ; dev@dpdk.org;
> sovar...@linux.microsoft.com
> Cc: tho...@monjalon.net
> Subject: [PATCH v2 1/2] examples/flow_classify: hooks for filters on tcp flags
>
> v2 fixes: typo fixes, get_tcp_flags returns -EINVAL
The above line should not be added to the commit message.
~/dpdk/devtools/check-git-log.sh -1
Wrong tag:
v2 fixes: typo fixes, get_tcp_flags returns -EINVAL
The check-git-log.sh script is in your dpdk checkout, best to run this script
before sending patches
>
> The rte_eth_ntuple_filter allows tcp_flags which can check for things like
> #define RTE_TCP_CWR_FLAG 0x80 /**< Congestion Window Reduced */
> #define RTE_TCP_ECE_FLAG 0x40 /**< ECN-Echo */
> #define RTE_TCP_URG_FLAG 0x20 /**< Urgent Pointer field significant */
> #define RTE_TCP_ACK_FLAG 0x10 /**< Acknowledgment field significant
> */
> #define RTE_TCP_PSH_FLAG 0x08 /**< Push Function */
> #define RTE_TCP_RST_FLAG 0x04 /**< Reset the connection */
> #define RTE_TCP_SYN_FLAG 0x02 /**< Synchronize sequence numbers */
> #define RTE_TCP_FIN_FLAG 0x01 /**< No more data from sender */ but
> there are no existing examples that demonstrate how to use this feature.
>
> This patch extends the existing classification support to allow an optional
> flags in the input file. The flags string can be any concatenation of
> characters
> from {C, E, U, A, P, R, S, F} and "*" indicates "don't care". These flags are
> set
> in the ntuple_filter and are used to construct the tcp_spec and tcp_mask
> sent to the driver
>
> The rte_acl_field_def is updated to use the (u8) tcp flag as lookup key.
> Note that, as per
> https://doc.dpdk.org/guides/prog_guide/packet_classif_access_ctrl.html
> this field MUST be allocated for 4 bytes, thus it has sizeof(uint32_t).
>
> However, also note the XXX in this commit: additional updates are needed to
> the rte_flow_classify_table_entry_add() so that it does not ignore any key
> fields other than the 5-tuple.
>
> Signed-off-by: Sowmini Varadhan
> ---
If you want comment on the patch updates (optional), it can be added here after
the --- line
> examples/flow_classify/flow_classify.c | 87 --
> examples/flow_classify/ipv4_rules_file.txt | 22 +++---
> 2 files changed, 91 insertions(+), 18 deletions(-)
>
> diff --git a/examples/flow_classify/flow_classify.c
> b/examples/flow_classify/flow_classify.c
> index db71f5aa04..ff4c8bc2f5 100644
> --- a/examples/flow_classify/flow_classify.c
> +++ b/examples/flow_classify/flow_classify.c
> @@ -51,6 +51,7 @@ enum {
> CB_FLD_DST_PORT_MASK,
> CB_FLD_PROTO,
> CB_FLD_PRIORITY,
> + CB_FLD_TCP_FLAGS,
> CB_FLD_NUM,
> };
>
> @@ -86,6 +87,7 @@ enum {
> DST_FIELD_IPV4,
> SRCP_FIELD_IPV4,
> DSTP_FIELD_IPV4,
> + TCP_FLAGS_FIELD,
I think it would be better to rename TCP_FLAGS_FIELD to TCP_FLAGS_FIELD_IPV4
inline with the other values.
> NUM_FIELDS_IPV4
> };
>
> @@ -93,7 +95,8 @@ enum {
> PROTO_INPUT_IPV4,
> SRC_INPUT_IPV4,
> DST_INPUT_IPV4,
> - SRCP_DESTP_INPUT_IPV4
> + SRCP_DESTP_INPUT_IPV4,
> + TCP_FLAGS_INDEX,
I think it would be better to rename TCP_FLAGS_INDEX to TCP_FLAGS_INPUT_IPV4
inline with the other values.
> };
>
> static struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = { @@ -150,6
> +153,17 @@ static struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
> sizeof(struct rte_ipv4_hdr) +
> offsetof(struct rte_tcp_hdr, dst_port),
> },
> + /* next field must be 4 bytes, even though flags is only 1 byte */
> + {
> + /* rte_flags */
> + .type = RTE_ACL_FIELD_TYPE_BITMASK,
> + .size = sizeof(uint32_t),
> + .field_index = TCP_FLAGS_FIELD,
> + .input_index = TCP_FLAGS_INDEX,
> + .offset = sizeof(struct rte_ether_hdr) +
> + sizeof(struct rte_ipv4_hdr) +
> + offsetof(struct rte_tcp_hdr, tcp_flags),
> + },
> };
> /* >8 End of creation of ACL table. */
>
> @@ -285,12 +299,14 @@ lcore_main(struct flow_classifier *cls_app)
> int ret;
> int i = 0;
>
> - ret = rte_flow_classify_table_entry_delete(cls_app->cls,
> - rules[7]);
> - if (ret)
> - printf("table_entry_delete failed [7] %d\n\n", ret);
> - else
> -
Re: [dpdk-dev] [PATCH v2 2/2] examples/flow_classify: add an ACL table for tcp
Hi Sowmini, Looking closer at this patchset, I am not sure that a second ACL table is needed. The existing ACL table handles UDP, TCP and SCP, however it is not processing the TCP flags. I think it just needs to be modified to process the TCP flags. Could you take another look to see if the above proposed solution will work for you. Regards, Bernard. > -Original Message- > From: Sowmini Varadhan > Sent: Thursday, August 19, 2021 4:21 PM > To: Iremonger, Bernard > Cc: sowmin...@gmail.com; dev@dpdk.org; tho...@monjalon.net > Subject: Re: [PATCH v2 2/2] examples/flow_classify: add an ACL table for tcp > > On (08/19/21 15:06), Iremonger, Bernard wrote: > > > v2 updates: typo fixes for checkpatch, bernard.iremonger comments > > > > The above line should not be added to the commit message. > > ~/dpdk/devtools/check-git-log.sh -1 > > Wrong tag: > > v2 fixes: typo fixes, get_tcp_flags returns -EINVAL > > > > The check-git-log.sh script is in your dpdk checkout, best to run this > > script > before sending patches > > apologies, I was not aware of this, I will fix and send out v3. > I did run check-git-log.sh but before editing the vX updates. > > thanks for your patience. > > --Sowmini
RE: [PATCH] examples/flow_classify: fix spelling when log error
Hi Chuanshe,
> -Original Message-
> From: Chuanshe Zhang
> Sent: Tuesday, January 18, 2022 2:50 AM
> To: dev@dpdk.org
> Cc: Iremonger, Bernard
> Subject: [PATCH] examples/flow_classify: fix spelling when log error
>
> Signed-off-by: Chuanshe Zhang
> ---
> examples/flow_classify/flow_classify.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/examples/flow_classify/flow_classify.c
> b/examples/flow_classify/flow_classify.c
> index 6185b34..97708b7 100644
> --- a/examples/flow_classify/flow_classify.c
> +++ b/examples/flow_classify/flow_classify.c
> @@ -430,7 +430,7 @@ struct rte_flow_query_count count = {
> &ntuple_filter->dst_ip,
> &ntuple_filter->dst_ip_mask);
> if (ret != 0) {
> - flow_classify_log("failed to read source address/mask:
> %s\n",
> + flow_classify_log("failed to read destination address/mask:
> %s\n",
> in[CB_FLD_DST_ADDR]);
> return ret;
> }
> --
> 1.8.3.1
/dpdk_22_03/devtools# ./checkpatches.sh
examples-flow_classify-fix-spelling-when-log-error.patch
### [PATCH] examples/flow_classify: fix spelling when log error
WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
/dpdk_22_03/devtools# ./check-git-log.sh -1
Missing 'Fixes' tag:
examples/flow_classify: fix spelling when log error
Otherwise, the fix looks good.
Regards,
Bernard.
RE: [PATCH] examples/flow_classify: fix spelling when log error
Hi Thomas,
> -Original Message-
> From: Thomas Monjalon
> Sent: Tuesday, March 8, 2022 11:44 AM
> To: Chuanshe Zhang
> Cc: dev@dpdk.org; Iremonger, Bernard
> Subject: Re: [PATCH] examples/flow_classify: fix spelling when log error
>
> 23/02/2022 17:05, Iremonger, Bernard:
> > Hi Chuanshe,
> >
> > From: Chuanshe Zhang
> > >
> > > Signed-off-by: Chuanshe Zhang
> > > ---
> > > - flow_classify_log("failed to read source address/mask:
> > > %s\n",
> > > + flow_classify_log("failed to read destination address/mask:
> > > %s\n",
> >
> > ### [PATCH] examples/flow_classify: fix spelling when log error
> > WARNING:COMMIT_MESSAGE: Missing commit description - Add an
> > appropriate one
> >
> > /dpdk_22_03/devtools# ./check-git-log.sh -1 Missing 'Fixes' tag:
> > examples/flow_classify: fix spelling when log error
> >
> > Otherwise, the fix looks good.
>
> Applied, thanks.
>
You can add my ack to this patch
Re: [dpdk-dev] [PATCH] crypto/qat: fix NULL authentication request
Hi Adam,
> -Original Message-
> From: dev On Behalf Of Zhang, Roy Fan
> Sent: Monday, May 10, 2021 12:42 PM
> To: Dybkowski, AdamX ; dev@dpdk.org;
> Kusztal, ArkadiuszX ; gak...@marvell.com
> Subject: Re: [dpdk-dev] [PATCH] crypto/qat: fix NULL authentication request
>
> > -Original Message-
> > From: Dybkowski, AdamX
> > Sent: Monday, May 10, 2021 11:20 AM
> > To: dev@dpdk.org; Zhang, Roy Fan ; Kusztal,
> > ArkadiuszX ; gak...@marvell.com
> > Cc: Dybkowski, AdamX
> > Subject: [PATCH] crypto/qat: fix NULL authentication request
> >
> > This patch fixes the NULL auth generation case where the request
> > shouldn't contain the authentication result address. Allows to run
> > ipsec_autotest with a QAT device.
> >
> > Fixes: 65beb9abca6d ("crypto/qat: fix null auth when using VFIO")
> >
> > Signed-off-by: Adam Dybkowski
> > ---
> > drivers/crypto/qat/qat_sym.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/crypto/qat/qat_sym.c
> > b/drivers/crypto/qat/qat_sym.c index a1f5676c04..9415ec7d32 100644
> > --- a/drivers/crypto/qat/qat_sym.c
> > +++ b/drivers/crypto/qat/qat_sym.c
> > @@ -399,8 +399,10 @@ qat_sym_build_request(void *in_op, uint8_t
> > *out_msg,
> > }
> > min_ofs = auth_ofs;
> >
> > - auth_param->auth_res_addr =
> > - op->sym->auth.digest.phys_addr;
> > + if (ctx->qat_hash_alg != ICP_QAT_HW_AUTH_ALGO_NULL
> ||
> > + ctx->auth_op ==
> > ICP_QAT_HW_AUTH_VERIFY)
> > + auth_param->auth_res_addr =
> > + op->sym->auth.digest.phys_addr;
> >
> > }
> >
> > --
> > 2.25.1
>
> Acked-by: Fan Zhang
This patch should be backported, the following line should be added after the
Fixes line:
Cc: sta...@dpdk.org
Regards,
Bernard.
Re: [dpdk-dev] [PATCH 00/31] Support VFD and DPDK PF + kernel VF on i40e
Hi Andrew, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Andrew Rybchenko > Sent: Friday, December 2, 2016 9:00 AM > To: Lu, Wenzhuo ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 00/31] Support VFD and DPDK PF + kernel VF > on i40e > > On 12/02/2016 03:11 AM, Wenzhuo Lu wrote: > > 1, VF Daemon (VFD) > > VFD is an idea to control all the VFs from PF. > > As we need to support the scenario kernel PF + DPDK VF, DPDK follows > > the interface between kernel PF + kernel VF. We don't want to > > introduce too many new messages between PF and VF. So this patch set > > adds some new APIs to control VFs directly from PF. > > The new APIs include, > > 1) set VF MAC anti-spoofing > > 2) set VF VLAN anti-spoofing > > 3) set TX loopback > > 4) set VF unicast promiscuous mode > > 5) set VF multicast promiscuous mode > > 6) set VF MTU > > 7) get/reset VF stats > > 8) set VF MAC address > > 9) set VF VLAN stripping > > 10) VF VLAN insertion > > 12) set VF broadcast mode > > 12) set VF VLAN tag > > 13) set VF VLAN filter > > VFD also includes VF to PF mailbox message management by APP. When PF > > receives mailbox messages from VF, PF should call the callback > > provided by APP to know if they're permitted to be processed. > > The patch series adds i40e-specific API functions for VF control (advertise > link > status change, MAC anti-spoofing, VLAN anti-spoofing, promiscuous mode, > MAC change, VLAN controls), but RTE API is added to get VF stats. I'm > wondering why. > Corresponding patches do not explain why i40e-specific API is added instead > of generic RTE API. IMHO, it is hardly convenient for applications. > (I guess it was a discussion and decision, but I've failed to find in the > archive). > > Andrew. There was a discussion previously in DPDK 16.11 about this approach being used for the ixgbe PMD. I have attached the email thread. Regards, Bernard.
Re: [dpdk-dev] [PATCH 00/31] Support VFD and DPDK PF + kernel VF on i40e
Hi Andrew, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Iremonger, Bernard > Sent: Friday, December 2, 2016 10:59 AM > To: Andrew Rybchenko ; Lu, Wenzhuo > ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 00/31] Support VFD and DPDK PF + kernel VF > on i40e > > Hi Andrew, > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Andrew > Rybchenko > > Sent: Friday, December 2, 2016 9:00 AM > > To: Lu, Wenzhuo ; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 00/31] Support VFD and DPDK PF + kernel > > VF on i40e > > > > On 12/02/2016 03:11 AM, Wenzhuo Lu wrote: > > > 1, VF Daemon (VFD) > > > VFD is an idea to control all the VFs from PF. > > > As we need to support the scenario kernel PF + DPDK VF, DPDK follows > > > the interface between kernel PF + kernel VF. We don't want to > > > introduce too many new messages between PF and VF. So this patch set > > > adds some new APIs to control VFs directly from PF. > > > The new APIs include, > > > 1) set VF MAC anti-spoofing > > > 2) set VF VLAN anti-spoofing > > > 3) set TX loopback > > > 4) set VF unicast promiscuous mode > > > 5) set VF multicast promiscuous mode > > > 6) set VF MTU > > > 7) get/reset VF stats > > > 8) set VF MAC address > > > 9) set VF VLAN stripping > > > 10) VF VLAN insertion > > > 12) set VF broadcast mode > > > 12) set VF VLAN tag > > > 13) set VF VLAN filter > > > VFD also includes VF to PF mailbox message management by APP. When > > > PF receives mailbox messages from VF, PF should call the callback > > > provided by APP to know if they're permitted to be processed. > > > > The patch series adds i40e-specific API functions for VF control > > (advertise link status change, MAC anti-spoofing, VLAN anti-spoofing, > > promiscuous mode, MAC change, VLAN controls), but RTE API is added to > > get VF stats. I'm wondering why. > > Corresponding patches do not explain why i40e-specific API is added > > instead of generic RTE API. IMHO, it is hardly convenient for applications. > > (I guess it was a discussion and decision, but I've failed to find in the > archive). > > > > Andrew. > > There was a discussion previously in DPDK 16.11 about this approach being > used for the ixgbe PMD. > I have attached the email thread. > > Regards, > > Bernard. The attached email did not get through for some reason. Here is a link to the email archive. http://dpdk.org/ml/archives/dev/2016-September/047786.html Regards, Bernard.
Re: [dpdk-dev] [PATCH 00/31] Support VFD and DPDK PF + kernel VF on i40e
Hi Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Friday, December 2, 2016 2:16 PM > To: Lu, Wenzhuo ; Iremonger, Bernard > ; Yigit, Ferruh > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 00/31] Support VFD and DPDK PF + kernel VF > on i40e > > Do you agree to copy the remaining VF-specific functions from the generic > ethdev API to ixgbe in 17.02? > After a deprecation notice, we could remove them from the generic API in > 17.05. > So we will have a consistent status in 17.05 regarding VF functions. > > After some time (and experience) we will be able to discuss wether we need > something more to access to these specific features. I had intended to copy the remaining VF-specific functions from the generic ethdev API to ixgbe in 17.02 and a deprecation notice was sent in 16.11. This work was parked in order work on the VF-specfic functionsfor the i40e. Is it ok to submit patches for this work after the V1 deadline (today)? Regards, Bernard.
[dpdk-dev] [PATCH v5 1/4] doc: Added new commands in testpmd UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Monday, December 1, 2014 11:41 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 1/4] doc: Added new commands in testpmd UG > > Added info in testpmd functions section for the following commands: > > - tunnel_filter add > - tunnel_filter rm > - rx_vxlan_port add > - rx_vxlan_port rm > - port stop/start queue > - set port mac address filter (for VF) > - tx_checksum set > - tso set > - tso show > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v5 2/4] doc: Corrected info for tx_checksum set mask function, in testpmd UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Monday, December 1, 2014 11:41 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 2/4] doc: Corrected info for tx_checksum set > mask function, in > testpmd UG > > tx_checksum set function does not use bitmask anymore, but strings > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v5 3/4] doc: Moved commands in testpmd UG to match testpmd command help order
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Monday, December 1, 2014 11:41 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 3/4] doc: Moved commands in testpmd UG to match > testpmd > command help order > > Moved commands in testpmd UG to set queue rates to match order in testpmd > command help. > > Created new section "Filters" to match that same section in testpmd UG, and > moved all commands > related to it there. > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v5 4/4] doc: Various document fixes in testpmd UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Monday, December 1, 2014 11:41 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v5 4/4] doc: Various document fixes in testpmd UG > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] doc: link bonding related updates to programmers guide
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty > Sent: Monday, December 1, 2014 5:10 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: link bonding related updates to programmers > guide > > Adding details for link status interrupts and link status polling. > Adding details for mode 4 / mode 5 > Tidying up rst document to conform to 80 character line limit > Adding diagrams to explain bonding modes > > Signed-off-by: Declan Doherty Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] Doc: Adding Distributor Sample Application to Sample App UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Tuesday, December 2, 2014 2:03 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] Doc: Adding Distributor Sample Application to > Sample App UG > > New distributor sample app user guide section for sample app ug. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] doc: patch to include vhost library UG section in PG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Tuesday, December 2, 2014 9:12 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: patch to include vhost library UG section in > PG > > As Vhost will be a library in DPDK 1.8, adding a new section to Programmer's > Guide to describe its use. > > Signed-off-by: Siobhan Butler > > Signed-off-by: Huawei Xie Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH 1/2] doc: updated i40e enabling additonal fnct in gsg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Tuesday, December 2, 2014 11:41 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 1/2] doc: updated i40e enabling additonal fnct in > gsg > > Updated the i40e Enabling Additional Functionality section (5.7) of DPDK > Getting Started Guide. > > Signed-off-by: Siobhan Butler > > Signed-off-by: Helin Zhang Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH 2/2] doc: remove references to intel dpdk in linux_gsg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Tuesday, December 2, 2014 11:41 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 2/2] doc: remove references to intel dpdk in > linux_gsg > > Adjusted line lengths and removed references to Intel which > are no longer relevant in linux gsg. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PULL REQUEST] doc: document modifications in user guides
Hi Thomas, > Hi Bernard, > > These patches won't pulled as is for 2 reasons: > 1) I made some comments recently on some of these patches Clearly I was too eager to apply these patches. Are you happy with of the patches, if so I could a send a request pull with a reduced patch set > 2) It appears you didn't applied the v5 of Pablo's patchset > http://dpdk.org/ml/archives/dev/2014-December/009270.html There was conflict with Pablo's earlier patch set when I synced up with dpdk_main, which I thought I had resolved incorrectly. When I applied the V5 patch set, I reworked this line "Quit to prompt:", so it should be correct now. I can rebase and reapply Pablo's V5 patch set if that is a better solution. > Below some title rewording to make it concise and more consistent: > > 2014-12-03 15:50, Bernard Iremonger: > > Bruce Richardson (3): > > doc: change hardcoded date to auto-generated in guide documents > doc: auto-generate date in guides > > doc: adjust line lengths in freebsd getting started guide rst files > doc: adjust line lengths in freebsd guide > > doc: update freebsd getting started guide to document ports install > doc: add freebsd ports > > > > Doherty, Declan (1): > > doc: link bonding related updates to programmers guide > doc: update bonding > > > > Pablo de Lara (4): > > doc: added new commands in testpmd application user guide > doc: new testpmd commands > > doc: fix commands in testpmd application user guide > doc: fix testpmd commands > > doc: moved commands in testpmd application user guide to match > > testpmd command help order > doc: reorder testpmd commands > > doc: fixes in testpmd application user guide > doc: fix testpmd guide > > > > Siobhan Butler (4): > > doc: added distributor sample application to the sample application > > user guide > doc: add distributor application > > doc: add vhost library section in programmers guide > doc: add vhost library > > doc: updated i40e enabling additonal functionality in linux getting > > started guide > doc: update i40e > > doc: remove references to intel dpdk in linux getting started guide > Are the reworded commit lines ok now. > -- > Thomas Regards, Bernard.
[dpdk-dev] [PATCH 4/4] doc: Various document fixes in testpmd UG
Hi Thomas, > Subject: Re: [dpdk-dev] [PATCH 4/4] doc: Various document fixes in testpmd UG > > 2014-11-15 19:13, Pablo de Lara: > > --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > > +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > [...] > > -Quit to prompt in Linux or reboot on Baremetal: > > +Quit to prompt in Linux/FreeBSD or reboot on Baremetal: > > Bare-metal traces have been removed. My attempt to resolve a conflict with this line has caused confusion. I had not noticed that the Bare-metal patch had also updated the doc's, and referred to the original MSWord document. > > -- > Thomas Bernard.
[dpdk-dev] [PATCH 2/3] docs: adjust line lengths in FreeBSD GSG rst files
Hi Bruce, Thomas, > Subject: Re: [dpdk-dev] [PATCH 2/3] docs: adjust line lengths in FreeBSD GSG > rst files > > On Wed, Dec 03, 2014 at 02:23:44PM +0100, Thomas Monjalon wrote: > > 2014-11-24 15:48, Bruce Richardson: > > > The FreeBSD GSG rst files had very inconsistent line lengths for > > > text within paragraph blocks. Sometimes a line would be very short, > > > while often lines would be quite long. > > > This patch adjusts the formatting of the rst files so that lines > > > break at approx the 80-character mark, as is standard in the DPDK source > > > code. > > > > I'm not sure we should be strict with line lengths in the doc. > > The most important thing is to limit the wrapping impact of future patches. > > Starting a new sentence at the beginning of the line is often a good > > way to keep context lines unchanged when updating only one sentence. > > Don't forget that a carriage return in rst has no impact on generated doc. > > > > -- > > Thomas > > Hi Thomas, > I agree that we shouldn't be strict, but the variance in line length was > really huge, and shorter lines are > always easier to read. Even my patch just limited line length to somethign > between 80-90 depending > on wording, since a hard-80 I feel is too extreme. > > /Bruce When converting the documents originally I chose to wrap sentences that were longer than 120-130 characters. I normally wrapped at a punctuation point for readability. So a long sentence might wrap over several lines. Sentences shorter than 130 characters were given a separate line. I don't think there is anything to be gained by reworking the line lengths as it has no effect on the generated HTML. Bernard.
[dpdk-dev] [PATCH] doc: typos corrected in distributor application
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Reshma Pattan > Sent: Friday, December 5, 2014 4:08 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: typos corrected in distributor application > > corrected couple of typos in distributor application > > Signed-off-by: Reshma Pattan Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] doc: add license header to link bonding diagrams
> -Original Message- > From: Doherty, Declan > Sent: Monday, December 8, 2014 11:22 AM > To: dev at dpdk.org > Cc: Iremonger, Bernard; Doherty, Declan > Subject: [PATCH] doc: add license header to link bonding diagrams > > > Signed-off-by: Declan Doherty Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] doc: fix typos in ring lib
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Tuesday, December 9, 2014 12:28 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: fix typos in ring lib > > Ring library section in PG had a couple of typos, in the text and in one of > the images > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v3 1/3] doc: add vm power mgmt overview svg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Tuesday, December 9, 2014 12:02 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 1/3] doc: add vm power mgmt overview svg > > Added first of the two figures in the VM power management app UG: > VM power mangament highlevel overview > > Signed-off-by: Alan Carew > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v3 2/3] doc: add vm power mgmt request sequence svg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Tuesday, December 9, 2014 12:02 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 2/3] doc: add vm power mgmt request sequence svg > > Added second of the two figures in the VM power management app UG VM power > management > request sequence > > Signed-off-by: Alan Carew > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v3 3/3] doc: add VM power mgmt app
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Tuesday, December 9, 2014 12:02 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v3 3/3] doc: add VM power mgmt app > > Added new section in sample app UG for > the new VM power management app. > > Signed-off-by: Alan Carew > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] doc: Add IBM Power description to linux guides
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chao Zhu > Sent: Saturday, December 13, 2014 3:06 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: Add IBM Power description to linux guides > > This patch added IBM ppc_64 descriptions, including architecture support, > compiling requirements on > Linux. > > Signed-off-by: Chao Zhu Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v4] doc: add known issue for iommu and igb_uio
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio Gonzalez Monroy > Sent: Monday, December 15, 2014 10:33 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4] doc: add known issue for iommu and igb_uio > > Known issue regarding iommu/VT-d and igb_uio in Linux kernel version 3.15 to > 3.17 where unbinding > the device from the driver removes the 1:1 mapping in the iommu resulting in > IOMMU/DMAR errors > when the device tries to access memory. > > Signed-off-by: Sergio Gonzalez Monroy Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] doc: remove intel legal info from freebsd-gsg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Tuesday, December 16, 2014 10:57 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: remove intel legal info from freebsd-gsg > > Removed redundant legal blurb from FreeBSD GSG > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v2] doc: remove redundant intel references-freebsd gsg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Tuesday, December 16, 2014 10:50 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2] doc: remove redundant intel references-freebsd > gsg > > Updated the FreeBSD GSG to remove redundant Intel references. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v2] doc: fix setup menu options in linux gsg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Reshma Pattan > Sent: Wednesday, December 17, 2014 1:11 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2] doc: fix setup menu options in linux gsg > > From: Reshma Pattan > > v2 changes: > fixed setup menu options in linux gsg to > keep in synch with setup.sh > > Signed-off-by: Reshma Pattan Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH 1/2] doc: removed intel references from testpmd_ug
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Wednesday, December 17, 2014 4:59 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 1/2] doc: removed intel references from testpmd_ug > > Removed redundant Intel references from TestPMD User Guide. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH 2/2] doc: removed intel legal blurb from testpmd_ug
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Wednesday, December 17, 2014 4:59 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 2/2] doc: removed intel legal blurb from testpmd_ug > > Removed Intel Legal blurb from TestPMD User Guide. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v4 3/8] doc: added to known issue 6.10 and removed fixed issue 6.29 from rel_notes
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Wednesday, December 17, 2014 4:58 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 3/8] doc: added to known issue 6.10 and removed > fixed issue 6.29 > from rel_notes > > From: Siobhan Butler > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v4 1/8] doc: moved 1.7 new features to supported features for 1.8 in Rel_Notes
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Wednesday, December 17, 2014 4:48 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 1/8] doc: moved 1.7 new features to supported > features for 1.8 in > Rel_Notes > > From: Siobhan Butler > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v4 5/8] doc: remove appendix a from release notes
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Wednesday, December 17, 2014 4:48 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 5/8] doc: remove appendix a from release notes > > From: Siobhan Butler > > Removing Appendix A from Release Notes as Intel Licensing information is no > longer relevant in this > document. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v4 2/8] doc: added new features to release notes
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Wednesday, December 17, 2014 4:48 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 2/8] doc: added new features to release notes > > From: Siobhan Butler > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v4 7/8] doc: updated resolved issues with old known issues
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Wednesday, December 17, 2014 4:48 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 7/8] doc: updated resolved issues with old > known issues > > From: Siobhan Butler > > Removed resolved issues from known issues section. > Added new resolved issues to resolved issues section. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v4 4/8] doc: moved known issue 6.29 to resolved issues in rel notes
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Wednesday, December 17, 2014 4:48 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 4/8] doc: moved known issue 6.29 to resolved > issues in rel notes > > From: Siobhan Butler > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v4 8/8] doc: updating the list of sample apps in rel notes
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Wednesday, December 17, 2014 4:48 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 8/8] doc: updating the list of sample apps in > rel notes > > From: Siobhan Butler > > Added new and existing names of sample apps to list of sample apps in release > notes. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v4 6/8] doc: removed reference to Intel DPDK in Rel Notes
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Wednesday, December 17, 2014 4:48 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 6/8] doc: removed reference to Intel DPDK in > Rel Notes > > From: Siobhan Butler > > Removed multiple references to Intel(R) DPDK where no longer > relevant. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] doc:add udp info to prog_guide for vxlan
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Thursday, December 18, 2014 3:02 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc:add udp info to prog_guide for vxlan > > Added to configuration instructions for UDP packet tunneling. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v2 1/2] doc: remove intel dpdk in sample app ug
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Thursday, December 18, 2014 10:51 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 1/2] doc: remove intel dpdk in sample app ug > > Removed redundant references to Intel(R) DPDK in Sample App UG. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v2 2/2] doc: remove intel legal blurb from sample app ug
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Thursday, December 18, 2014 4:04 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 2/2] doc: remove intel legal blurb from sample > app ug > > Removed Legal blurb from sample applications guide. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH 2/2] doc: updating from 1.7 to 1.8 release note
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Thursday, December 18, 2014 2:52 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 2/2] doc: updating from 1.7 to 1.8 release note > > Added instructions for updating from DPDK 1.7.0 to 1.8.0 > > Signed-off-by: Siobhan Butler > > Signed-off-by: Bruce Richardson Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH 1/2] doc: add vxlan support to release notes
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Thursday, December 18, 2014 2:52 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 1/2] doc: add vxlan support to release notes > > Added to New and Supported features for VXLAN feature. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH] doc: added copyright to dist sample app images
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler > Sent: Thursday, December 18, 2014 4:35 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: added copyright to dist sample app images > > Added copyright to distributor sample app images. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH 1/2] doc: update mbuf section of programmer's guide for 1.8
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson > Sent: Tuesday, December 2, 2014 4:18 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 1/2] doc: update mbuf section of programmer's > guide for 1.8 > > In Release 1.8, the mbuf structure was significantly reworked to add extra > information, leading to the > structure being split across two cache lines, and the data pointer being > replaced by an offset. The > description of the library in the programmer's guide document needs to be > updated to take account of > these changes. > > Signed-off-by: Bruce Richardson Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v2 2/2] doc: Updated image files for rte_mbuf changes in 1.8
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson > Sent: Friday, December 12, 2014 11:22 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 2/2] doc: Updated image files for rte_mbuf > changes in 1.8 > > The two image files showing the structure of the rte_mbuf data structure > required some minor > updates to take account of the changes introduced to the structure in the 1.8 > release > > Signed-off-by: Bruce Richardson Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH 1/2] doc: remove intel dpdk from prog_guide
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Friday, December 19, 2014 2:31 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 1/2] doc: remove intel dpdk from prog_guide > > From: Siobhan Butler > > Removed redundant references to Intel(R) DPDK in Programmers Guide. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH 2/2] doc: removed intel blurb from prog_guide
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Friday, December 19, 2014 2:31 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 2/2] doc: removed intel blurb from prog_guide > > From: Siobhan Butler > > Removed redundant Intel legal blurb from programmers guide. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v2 1/3] doc: updated i40e enabling additonal fnct in gsg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Friday, December 19, 2014 3:09 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 1/3] doc: updated i40e enabling additonal fnct > in gsg > > From: Siobhan Butler > > Updated the i40e Enabling Additional Functionality section (5.7) of DPDK > Getting Started Guide. > > Signed-off-by: Siobhan Butler > > Signed-off-by: Helin Zhang Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v2 2/3] doc: remove references to intel dpdk in linux_gsg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Friday, December 19, 2014 3:09 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 2/3] doc: remove references to intel dpdk in > linux_gsg > > From: Siobhan Butler > > Adjusted line lengths and removed references to Intel which are no longer > relevant in linux gsg. > > Signed-off-by: Siobhan Butler Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v2 3/3] doc: removed intel blurb from linux gsg
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Friday, December 19, 2014 3:09 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 3/3] doc: removed intel blurb from linux gsg > > Removed redundant Intel legal blurb from linux gsg. > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc.
[dpdk-dev] [PATCH v2 4/4] docs: Add ABI documentation
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > Sent: Monday, December 22, 2014 8:24 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 4/4] docs: Add ABI documentation > > Adding a document describing rudimentary ABI policy and adding notice space > for any deprecation > announcements > > Signed-off-by: Neil Horman > CC: Thomas Monjalon > CC: "Richardson, Bruce" > --- > doc/abi.txt | 17 + > 1 file changed, 17 insertions(+) > create mode 100644 doc/abi.txt > > diff --git a/doc/abi.txt b/doc/abi.txt > new file mode 100644 > index 000..b6dcc7d > --- /dev/null > +++ b/doc/abi.txt > @@ -0,0 +1,17 @@ > +ABI policy: > + ABI versions are set at the time of major release labeling, and ABI > +may change multiple times between the last labeling and the HEAD label > +of the git tree without warning > + > + ABI versions, once released are available until such time as their > +deprecation has been noted here for at least one major release cycle, > +after it has been tagged. E.g. the ABI for DPDK 1.8 is shipped, and > +then the decision to remove it is made during the development of DPDK > +1.9. The decision will be recorded here, shipped with the DPDK 1.9 > +release, and actually removed when DPDK > +1.10 ships. > + > + ABI versions may be deprecated in whole, or in part as needed by a > +given update. > + > +Deprecation Notices: > + > -- > 1.9.3 Should this document be added to the guides documentation (for example doc/guides/prog_guide)? Regards, Bernard.
[dpdk-dev] [PATCH v2 0/3] split programmers guide a bit
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, March 31, 2015 1:23 PM > To: Mcnamara, John > Cc: Butler, Siobhan A; Iremonger, Bernard; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > 2015-03-31 11:34, Mcnamara, John: > > Any objection to an additional patch to move the figure captions below > > the figures in the docs? > > No objection. > We should use figure:: keyword instead of image:: to add a caption. > > > The caption above the figure was the format used in the initial docs, > > and it looks okay in the HTML output, but in the PDF output it tends > > to get merged into the preceding paragraph and isn't always on the > > same page as the figure. > > Yes, it's a bit strange. > Why moving it below will ensure to keep it in the same page? > I think figure:: keyword may solve it. Hi John, My preference would be to keep the caption above the figure. This was the way it was done in the original 1.7 MSword documents (the starting point for the conversion to rst files). Regards, Bernard
[dpdk-dev] [PATCH v2 0/3] split programmers guide a bit
> -Original Message- > From: Mcnamara, John > Sent: Wednesday, April 1, 2015 5:37 PM > To: Iremonger, Bernard; Thomas Monjalon > Cc: Butler, Siobhan A; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > > -Original Message- > > From: Iremonger, Bernard > > Sent: Wednesday, April 1, 2015 10:19 AM > > To: Thomas Monjalon; Mcnamara, John > > Cc: Butler, Siobhan A; dev at dpdk.org > > Subject: RE: [dpdk-dev] [PATCH v2 0/3] split programmers guide a bit > > > > > > 2015-03-31 11:34, Mcnamara, John: > > > > Any objection to an additional patch to move the figure captions > > > > below the figures in the docs? > > > > > > No objection. > > > We should use figure:: keyword instead of image:: to add a caption. > > > > > > > The caption above the figure was the format used in the initial > > > > docs, and it looks okay in the HTML output, but in the PDF output > > > > it tends to get merged into the preceding paragraph and isn't > > > > always on the same page as the figure. > > > > > > Yes, it's a bit strange. > > > Why moving it below will ensure to keep it in the same page? > > > I think figure:: keyword may solve it. > > > > Hi John, > > > > My preference would be to keep the caption above the figure. > > This was the way it was done in the original 1.7 MSword documents (the > > starting point for the conversion to rst files). > > Hi Bernard, > > I don't mind the caption above. I'm mainly concerned with it staying with the > image. > > To do this we need to use the figure:: keyword as Thomas suggested. However, > there are some knock > on effects from this. > > * As far as I can see, we can't just replace with image:: with figure:: in > the |image-name| substitution > definitions since Sphinx or RST doesn't support it. > * This means that the |image-name| substitutions will have to change back to > explicit .. figure:: > declarations. Not a big deal. > * The captions have to be under the image. I don't see a way to configure it > to be on top. It may be > possible in LaTex but not in Html. > * We should also modify the table captions in the same way. > > So at this point I'm sorry I brought it up. I can post a programmatically > generated patch as an RFC if > there is interest in seeing what the updated output would look like. > > The main positive is that it would give us automatic* figure/table numbering > in Html and PDF and the > captioning looks quite good. (*This requires Sphinx 1.3). > > John > Hi John, I am not sure why the captions have to be under the images. At present the captions are just a bold line of text before the image in the rst files for example, **Figure 17. Components of a DPDK KNI Application** This will probably affect the cross reference links as well or does the automatic numbering work with the links as well. Regards, Bernard
[dpdk-dev] [PATCH v3 0/5] Clean up pci uio implementations
> -Original Message- > From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp] > Sent: Friday, March 27, 2015 8:39 AM > To: dev at dpdk.org > Cc: Iremonger, Bernard; Richardson, Bruce; david.marchand at 6wind.com; > Tetsuya Mukawa > Subject: [PATCH v3 0/5] Clean up pci uio implementations > > This patch set cleans up pci uio implementation. These clean up are for > consolidating pci uio > implementation of linuxapp and bsdapp, and moving consolidated functions in > eal common. > Because of above, this patch set tries to implement linuxapp and bsdapp > almost same. > Actual consolidations will be done later patch set. > > PATCH v3 changes: > - Squash patches related with pci_map_resource(). > - Free maps[].path to easy to understand. >(Thanks to Iremonger, Bernard) > - Close fds opened in this function. > - Remove unused path variable from mapped_pci_resource structure. > > PATCH v2 changes: > - Move 'if-condition' to later patch series. > - Fix memory leaks of path. > - Fix typos. >(Thanks to David Marchand) > - Fix commit title and body. > - Fix pci_map_resource() to handle MAP_FAILED. >(Thanks to Iremonger, Bernard) > > Changes: > - This patch set is derived from below. >"[PATCH v2] eal: Port Hotplug support for BSD" > - Set cfg_fd as -1, when cfg_fd is closed. >(Thanks to Iremonger, Bernard) > - Remove needless coding style fixings. > - Fix coding style of if-else condition. >(Thanks to Richardson, Bruce) > > > > Tetsuya Mukawa (5): > eal: Fix coding style of eal_pci.c and eal_pci_uio.c > eal: Close file descriptor of uio configuration > eal: Fix memory leaks and needless increment of pci_map_addr > eal/bsdapp: Change names of pci related data structure > eal: Fix uio mapping differences between linuxapp and bsdapp > > lib/librte_eal/bsdapp/eal/eal_pci.c| 166 > + > lib/librte_eal/linuxapp/eal/eal_pci_init.h | 1 - > lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 91 +--- > 3 files changed, 154 insertions(+), 104 deletions(-) > > -- > 1.9.1 Series Acked-by: Bernard Iremonger
[dpdk-dev] [PATCH v3 0/5] Clean up pci uio implementations
> -Original Message- > From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp] > Sent: Thursday, April 23, 2015 5:24 AM > To: Iremonger, Bernard; dev at dpdk.org > Cc: Richardson, Bruce; david.marchand at 6wind.com > Subject: Re: [PATCH v3 0/5] Clean up pci uio implementations > > On 2015/04/21 22:15, Iremonger, Bernard wrote: > >> -Original Message- > >> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp] > >> Sent: Friday, March 27, 2015 8:39 AM > >> To: dev at dpdk.org > >> Cc: Iremonger, Bernard; Richardson, Bruce; david.marchand at 6wind.com; > >> Tetsuya Mukawa > >> Subject: [PATCH v3 0/5] Clean up pci uio implementations > >> > >> This patch set cleans up pci uio implementation. These clean up are > >> for consolidating pci uio implementation of linuxapp and bsdapp, and > >> moving consolidated > functions in eal common. > >> Because of above, this patch set tries to implement linuxapp and bsdapp > >> almost same. > >> Actual consolidations will be done later patch set. > >> > >> PATCH v3 changes: > >> - Squash patches related with pci_map_resource(). > >> - Free maps[].path to easy to understand. > >>(Thanks to Iremonger, Bernard) > >> - Close fds opened in this function. > >> - Remove unused path variable from mapped_pci_resource structure. > >> > >> PATCH v2 changes: > >> - Move 'if-condition' to later patch series. > >> - Fix memory leaks of path. > >> - Fix typos. > >>(Thanks to David Marchand) > >> - Fix commit title and body. > >> - Fix pci_map_resource() to handle MAP_FAILED. > >>(Thanks to Iremonger, Bernard) > >> > >> Changes: > >> - This patch set is derived from below. > >>"[PATCH v2] eal: Port Hotplug support for BSD" > >> - Set cfg_fd as -1, when cfg_fd is closed. > >>(Thanks to Iremonger, Bernard) > >> - Remove needless coding style fixings. > >> - Fix coding style of if-else condition. > >>(Thanks to Richardson, Bruce) > >> > >> > >> > >> Tetsuya Mukawa (5): > >> eal: Fix coding style of eal_pci.c and eal_pci_uio.c > >> eal: Close file descriptor of uio configuration > >> eal: Fix memory leaks and needless increment of pci_map_addr > >> eal/bsdapp: Change names of pci related data structure > >> eal: Fix uio mapping differences between linuxapp and bsdapp > >> > >> lib/librte_eal/bsdapp/eal/eal_pci.c| 166 > >> + > >> lib/librte_eal/linuxapp/eal/eal_pci_init.h | 1 - > >> lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 91 +--- > >> 3 files changed, 154 insertions(+), 104 deletions(-) > >> > >> -- > >> 1.9.1 > > Series > > Acked-by: Bernard Iremonger > Hi Bernard, > > Thanks for your checking. > It seems I need to rebase this patches for latest matser branch. > So I will update and submit it soon. > > Regards, > Tetsuya Hi Tetsuya, I applied the v3 patches to the latest master branch on Monday last and there were no issues. The patches built cleanly on Linux and Free BSD. Regards, Bernard.
Re: [dpdk-dev] [PATCH v7 14/27] net/i40e: set VF VLAN insertion from PF
Hi Jinqjing, Wenzhuo,
> -Original Message-
> From: Lu, Wenzhuo
> Sent: Friday, January 6, 2017 8:20 AM
> To: Wu, Jingjing ; dev@dpdk.org
> Cc: Iremonger, Bernard
> Subject: RE: [dpdk-dev] [PATCH v7 14/27] net/i40e: set VF VLAN insertion
> from PF
>
> Hi Jingjing, Bernard,
>
>
> > -Original Message-
> > From: Wu, Jingjing
> > Sent: Friday, January 6, 2017 8:33 AM
> > To: Lu, Wenzhuo; dev@dpdk.org
> > Cc: Iremonger, Bernard
> > Subject: RE: [dpdk-dev] [PATCH v7 14/27] net/i40e: set VF VLAN
> > insertion from PF
> >
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu
> > > Sent: Tuesday, January 3, 2017 2:55 PM
> > > To: dev@dpdk.org
> > > Cc: Iremonger, Bernard
> > > Subject: [dpdk-dev] [PATCH v7 14/27] net/i40e: set VF VLAN insertion
> > > from PF
> > >
> > > From: Bernard Iremonger
> > >
> > > Support inserting VF VLAN id from PF.
> > > User can call the API on PF to insert a VLAN id to a specific VF.
> > >
> > > Signed-off-by: Bernard Iremonger
> > > ---
> > > drivers/net/i40e/i40e_ethdev.c| 56
> > > +++
> > > drivers/net/i40e/rte_pmd_i40e.h | 19 +++
> > > drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> > > 3 files changed, 76 insertions(+)
> > >
> > > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > > b/drivers/net/i40e/i40e_ethdev.c index 7ab1c93..31c387d 100644
> > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > @@ -10266,3 +10266,59 @@ static void
> > > i40e_set_default_mac_addr(struct rte_eth_dev *dev,
> > > else
> > > return -EINVAL;
> > > }
> > > +
> > > +int rte_pmd_i40e_set_vf_vlan_insert(uint8_t port, uint16_t vf_id,
> > > + uint16_t vlan_id)
> > > +{
> > > + struct rte_eth_dev *dev;
> > > + struct rte_eth_dev_info dev_info;
> > > + struct i40e_pf *pf;
> > > + struct i40e_hw *hw;
> > > + struct i40e_vsi *vsi;
> > > + struct i40e_vsi_context ctxt;
> > > + int ret;
> > > +
> > > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> > > +
> > > + dev = &rte_eth_devices[port];
> > > + rte_eth_dev_info_get(port, &dev_info);
> >
> > It looks dev_info is not used in this function.
> I'll delete it.
It was intended to use dev_info have a check on max_vfs.
if (vf_id >= dev_info.max_vfs)
return -EINVAL;
Should this check be added instead of deleting dev_info ?
> >
> > > + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> > > + hw = I40E_PF_TO_HW(pf);
> > > +
> > > + /**
> > > + * return -ENODEV if SRIOV not enabled, VF number not configured
> > > + * or no queue assigned.
> > > + */
> > > + if (!hw->func_caps.sr_iov_1_1 || pf->vf_num == 0 ||
> > > + pf->vf_nb_qps == 0)
> > > + return -ENODEV;
> > > +
> > > + if (vf_id >= pf->vf_num || !pf->vfs)
> > > + return -EINVAL;
> > > +
> > > + if (vlan_id > ETHER_MAX_VLAN_ID)
> > > + return -EINVAL;
> > > +
> > > + vsi = pf->vfs[vf_id].vsi;
> > > + if (!vsi)
> > > + return -EINVAL;
> > > +
> > > + vsi->info.valid_sections =
> > > cpu_to_le16(I40E_AQ_VSI_PROP_VLAN_VALID);
> > > + vsi->info.pvid = vlan_id;
> > > + if (vlan_id > 0)
> > > + vsi->info.port_vlan_flags |=
> > I40E_AQ_VSI_PVLAN_INSERT_PVID;
> > > + else
> > > + vsi->info.port_vlan_flags &=
> > > ~I40E_AQ_VSI_PVLAN_INSERT_PVID;
> > So, Pvid is used here for insert. Does it has any relationship with
> > vlan anti- spoof patch?
> > If so, it's better to consider how to deal with that.
> It's vlan insertion not filtering. So I think not related.
>
> >
> > Thanks
> > Jingjing
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v7 17/27] net/i40e: set VF VLAN filter from PF
Hi Jinqjing,
> -Original Message-
> From: Wu, Jingjing
> Sent: Friday, January 6, 2017 12:37 AM
> To: Lu, Wenzhuo ; dev@dpdk.org
> Cc: Iremonger, Bernard
> Subject: RE: [dpdk-dev] [PATCH v7 17/27] net/i40e: set VF VLAN filter from
> PF
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu
> > Sent: Tuesday, January 3, 2017 2:55 PM
> > To: dev@dpdk.org
> > Cc: Iremonger, Bernard
> > Subject: [dpdk-dev] [PATCH v7 17/27] net/i40e: set VF VLAN filter from
> > PF
> >
> > From: Bernard Iremonger
> >
> > add rte_pmd_i40e_set_vf_vlan_filter API.
> > User can call the API on PF to enable/disable a set of VF's VLAN filters.
> >
> > Signed-off-by: Bernard Iremonger
> > ---
> > drivers/net/i40e/i40e_ethdev.c| 52
> > +++
> > drivers/net/i40e/rte_pmd_i40e.h | 22 +
> > drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> > 3 files changed, 75 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 4d2fb20..47e03d6 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -10428,3 +10428,55 @@ int rte_pmd_i40e_set_vf_vlan_tag(uint8_t
> > port, uint16_t vf_id, uint8_t on)
> >
> > return ret;
> > }
> > +
> > +int rte_pmd_i40e_set_vf_vlan_filter(uint8_t port, uint16_t vlan_id,
> > + uint64_t vf_mask, uint8_t on) {
> > + struct rte_eth_dev *dev;
> > + struct rte_eth_dev_info dev_info;
> > + struct i40e_pf *pf;
> > + uint16_t pool_idx;
> > + int ret = I40E_SUCCESS;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port];
> > + rte_eth_dev_info_get(port, &dev_info);
> > +
> > + if (vlan_id > ETHER_MAX_VLAN_ID)
> > + return -EINVAL;
> > +
> > + if (on > 1)
> > + return -EINVAL;
> > +
> > + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> > + if ((pf->flags & I40E_FLAG_VMDQ) == 0) {
> > + PMD_INIT_LOG(ERR, "Firmware doesn't support VMDQ");
> > + return -ENOTSUP;
> > + }
> > +
> > + if (!pf->vmdq) {
> > + PMD_INIT_LOG(INFO, "VMDQ not configured");
> > + return -ENOTSUP;
> > + }
> > +
> > + for (pool_idx = 0;
> > +pool_idx < ETH_64_POOLS &&
> > +pool_idx < pf->nb_cfg_vmdq_vsi &&
> > +ret == I40E_SUCCESS;
> > +pool_idx++) {
> > + if (vf_mask & ((uint64_t)(1ULL << pool_idx))) {
> > + if (on)
> > + ret = i40e_vsi_add_vlan(pf-
> >vmdq[pool_idx].vsi,
> > + vlan_id);
> > + else
> > + ret = i40e_vsi_delete_vlan(
> > + pf->vmdq[pool_idx].vsi, vlan_id);
> > + }
> > + }
>
> The head is saying "set VF VLAN filter", why do you deal with VMDQ VSIs?
This API is modelled on the rte_pmd_ixgbe_set_vf_vlan_filter(uint8_t port,
uint16_t vlan_id, uint64_t vf_mask, uint8_t on) which seems to use VMDq.
More investigation is needed here.
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v7 26/27] net/i40e: fix segmentation fault in close
Hi Jingjing,
> -Original Message-
> From: Wu, Jingjing
> Sent: Friday, January 6, 2017 1:29 AM
> To: Lu, Wenzhuo ; dev@dpdk.org
> Cc: Iremonger, Bernard ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v7 26/27] net/i40e: fix segmentation fault in
> close
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu
> > Sent: Tuesday, January 3, 2017 2:55 PM
> > To: dev@dpdk.org
> > Cc: Iremonger, Bernard ;
> sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH v7 26/27] net/i40e: fix segmentation fault
> > in close
> >
> > From: Bernard Iremonger
> >
> > The vsi's have already been released, so the second call to
> > i40e_vsi_release results in a segmentation fault.
> > The second call to i40e_vsi_release has been removed.
> Where is the first call to release vmdq vsi?
All of the VSI's are released in the call to i40e_vsi_release(pf->main_vsi) at
line 1895.
This function is recursive and release all the VSI's.
There is still a VSI address in pf->vmdq[i].vsi but calling
i40e_vsi_release(pf->vmdq[i].vsi);
Results in a segmentation fault.
>
> Thanks
> Jingjing
> >
> > Fixes: 3cb446b4aeb2 ("i40e: free vmdq vsi when closing")
> >
> > CC: sta...@dpdk.org
> >
> > Signed-off-by: Bernard Iremonger
> > ---
> > drivers/net/i40e/i40e_ethdev.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index be45cfa..0b7c366 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -1882,7 +1882,6 @@ static inline void i40e_GLQF_reg_init(struct
> > i40e_hw
> > *hw)
> > i40e_vsi_release(pf->main_vsi);
> >
> > for (i = 0; i < pf->nb_cfg_vmdq_vsi; i++) {
> > - i40e_vsi_release(pf->vmdq[i].vsi);
> > pf->vmdq[i].vsi = NULL;
> > }
> >
> > @@ -4137,6 +4136,9 @@ enum i40e_status_code
> > if (!vsi)
> > return I40E_SUCCESS;
> >
> > + if (!vsi->adapter)
> > + return I40E_ERR_BAD_PTR;
> > +
> > user_param = vsi->user_param;
> >
> > pf = I40E_VSI_TO_PF(vsi);
> > --
> > 1.9.3
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v7 26/27] net/i40e: fix segmentation fault in close
Hi Jingjing, > -Original Message- > From: Wu, Jingjing > Sent: Monday, January 9, 2017 9:44 AM > To: Iremonger, Bernard ; Lu, Wenzhuo > ; dev@dpdk.org > Cc: sta...@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v7 26/27] net/i40e: fix segmentation fault in > close > > > > > All of the VSI's are released in the call to > > i40e_vsi_release(pf->main_vsi) at line 1895. > > This function is recursive and release all the VSI's. > > > > There is still a VSI address in pf->vmdq[i].vsi but calling > > i40e_vsi_release(pf- > > >vmdq[i].vsi); > > Results in a segmentation fault. > > > Thanks for the clarification. > > You are correct. What I prefer is to move the code to release vmdq vsis to > before the i40e_vsi_release(pf->main_vsi); > > What do you think? > > Thanks > Jingjing I will test it and see what happens. Regards, Bernard.
Re: [dpdk-dev] [PATCH] ixgbe: fix wrong VMDq function name
> -Original Message-
> From: Lu, Wenzhuo
> Sent: Friday, January 6, 2017 2:31 AM
> To: dev@dpdk.org
> Cc: Iremonger, Bernard ; Lu, Wenzhuo
> ; sta...@dpdk.org
> Subject: [PATCH] ixgbe: fix wrong VMDq function name
>
> The function name ixgbe_vmdq_mode_check is not right.
> This function checks if Virtualization Technology is enabled. It's for both
> VMDq and IOV.
> Others may be misled by the current name.
>
> Fixes: fe3a45fd4104 ("ixgbe: add VMDq support")
>
> CC: sta...@dpdk.org
> Signed-off-by: Wenzhuo Lu
Acked-by: Bernard Iremonger
Re: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API calling
Hi Wenzhuo,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Wednesday, January 11, 2017 2:48 AM
> To: dev@dpdk.org
> Cc: Wu, Jingjing ; Lu, Wenzhuo
> ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API calling
>
> Some ixgbe private APIs are added to expose ixgbe specific functions.
> When they're used by testpmd, there's no check for if the NICs are ixgbe.
> Other NICs also have chance to call these APIs.
> This patch add the check and the feedback print.
I am not sure that testpmd is the right place to do this.
The rte_pmd_ixgbe_* functions are public API's which can be called by other
applications.
The checks should be in the rte_pmd_ixgbe_* API's
> Fixes: 425781ff5afe ("app/testpmd: add ixgbe VF management")
>
> CC: sta...@dpdk.org
> Signed-off-by: Wenzhuo Lu
> ---
> app/test-pmd/cmdline.c | 101
> +++--
> 1 file changed, 81 insertions(+), 20 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> f768b6b..172861a 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -10883,11 +10883,16 @@ struct cmd_vf_vlan_anti_spoof_result {
> __attribute__((unused)) void *data)
> {
> struct cmd_vf_vlan_anti_spoof_result *res = parsed_result;
> - int ret = 0;
> + int ret = -ENOTSUP;
> int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
> + struct rte_eth_dev_info dev_info;
>
> - ret = rte_pmd_ixgbe_set_vf_vlan_anti_spoof(res->port_id, res-
> >vf_id,
> - is_on);
> + rte_eth_dev_info_get(res->port_id, &dev_info);
> +
> + if (strstr(dev_info.driver_name, "ixgbe") != NULL)
> + ret = rte_pmd_ixgbe_set_vf_vlan_anti_spoof(res->port_id,
> +res->vf_id,
> +is_on);
> switch (ret) {
> case 0:
> break;
> @@ -10897,6 +10902,9 @@ struct cmd_vf_vlan_anti_spoof_result {
> case -ENODEV:
> printf("invalid port_id %d\n", res->port_id);
> break;
> + case -ENOTSUP:
> + printf("function not implemented\n");
> + break;
> default:
> printf("programming error: (%s)\n", strerror(-ret));
> }
> @@ -10968,11 +10976,16 @@ struct cmd_vf_mac_anti_spoof_result {
> __attribute__((unused)) void *data)
> {
> struct cmd_vf_mac_anti_spoof_result *res = parsed_result;
> - int ret;
> + int ret = -ENOTSUP;
> int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
> + struct rte_eth_dev_info dev_info;
>
> - ret = rte_pmd_ixgbe_set_vf_mac_anti_spoof(res->port_id, res-
> >vf_id,
> - is_on);
> + rte_eth_dev_info_get(res->port_id, &dev_info);
> +
> + if (strstr(dev_info.driver_name, "ixgbe") != NULL)
> + ret = rte_pmd_ixgbe_set_vf_mac_anti_spoof(res->port_id,
> + res->vf_id,
> + is_on);
> switch (ret) {
> case 0:
> break;
> @@ -10982,6 +10995,9 @@ struct cmd_vf_mac_anti_spoof_result {
> case -ENODEV:
> printf("invalid port_id %d\n", res->port_id);
> break;
> + case -ENOTSUP:
> + printf("function not implemented\n");
> + break;
> default:
> printf("programming error: (%s)\n", strerror(-ret));
> }
> @@ -11053,10 +11069,15 @@ struct cmd_vf_vlan_stripq_result {
> __attribute__((unused)) void *data)
> {
> struct cmd_vf_vlan_stripq_result *res = parsed_result;
> - int ret = 0;
> + int ret = -ENOTSUP;
> int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
> + struct rte_eth_dev_info dev_info;
>
> - ret = rte_pmd_ixgbe_set_vf_vlan_stripq(res->port_id, res->vf_id,
> is_on);
> + rte_eth_dev_info_get(res->port_id, &dev_info);
> +
> + if (strstr(dev_info.driver_name, "ixgbe") != NULL)
> + ret = rte_pmd_ixgbe_set_vf_vlan_stripq(res->port_id, res-
> >vf_id,
> +is_on);
> switch (ret) {
> case 0:
> break;
> @@ -11066,6 +11087,9 @@ struct cmd_vf_vlan_stripq_result {
> case -ENODEV:
> printf("invalid port_id %d\n", res->port_id);
> break;
> + case -ENOTSUP:
> + printf("function not implemented\n");
> + break;
> default:
> printf("programming error: (%s)\n", strerror(-ret));
> }
> @@ -11137,9 +11161,14 @@ struct cmd_vf_vlan_insert_result {
> __attribute__((unused)) void *data)
> {
> struct cmd_vf_vlan_insert_result *res = parsed_result;
> - int ret;
> + int ret = -ENOTSUP;
> + struct rte_eth_dev_info dev_info;
>
> - ret = rte_pmd_ixgbe_set_vf_vlan_insert(
Re: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API calling
Hi Wenzhuo,
> > Subject: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API calling
> >
> > Some ixgbe private APIs are added to expose ixgbe specific functions.
> > When they're used by testpmd, there's no check for if the NICs are ixgbe.
> > Other NICs also have chance to call these APIs.
> > This patch add the check and the feedback print.
>
> I am not sure that testpmd is the right place to do this.
> The rte_pmd_ixgbe_* functions are public API's which can be called by other
> applications.
> The checks should be in the rte_pmd_ixgbe_* API's
It is useful to handle the return code -ENOTSUP in testpmd.
> > Fixes: 425781ff5afe ("app/testpmd: add ixgbe VF management")
> >
> > CC: sta...@dpdk.org
> > Signed-off-by: Wenzhuo Lu
> > ---
> > app/test-pmd/cmdline.c | 101
> > +++--
> > 1 file changed, 81 insertions(+), 20 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > f768b6b..172861a 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -10883,11 +10883,16 @@ struct cmd_vf_vlan_anti_spoof_result {
> > __attribute__((unused)) void *data)
> > {
> > struct cmd_vf_vlan_anti_spoof_result *res = parsed_result;
> > - int ret = 0;
> > + int ret = -ENOTSUP;
> > int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
> > + struct rte_eth_dev_info dev_info;
> >
> > - ret = rte_pmd_ixgbe_set_vf_vlan_anti_spoof(res->port_id, res-
> > >vf_id,
> > - is_on);
> > + rte_eth_dev_info_get(res->port_id, &dev_info);
> > +
> > + if (strstr(dev_info.driver_name, "ixgbe") != NULL)
> > + ret = rte_pmd_ixgbe_set_vf_vlan_anti_spoof(res->port_id,
> > + res->vf_id,
> > + is_on);
> > switch (ret) {
> > case 0:
> > break;
> > @@ -10897,6 +10902,9 @@ struct cmd_vf_vlan_anti_spoof_result {
> > case -ENODEV:
> > printf("invalid port_id %d\n", res->port_id);
> > break;
> > + case -ENOTSUP:
> > + printf("function not implemented\n");
> > + break;
> > default:
> > printf("programming error: (%s)\n", strerror(-ret));
> > }
> > @@ -10968,11 +10976,16 @@ struct cmd_vf_mac_anti_spoof_result {
> > __attribute__((unused)) void *data)
> > {
> > struct cmd_vf_mac_anti_spoof_result *res = parsed_result;
> > - int ret;
> > + int ret = -ENOTSUP;
> > int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
> > + struct rte_eth_dev_info dev_info;
> >
> > - ret = rte_pmd_ixgbe_set_vf_mac_anti_spoof(res->port_id, res-
> > >vf_id,
> > - is_on);
> > + rte_eth_dev_info_get(res->port_id, &dev_info);
> > +
> > + if (strstr(dev_info.driver_name, "ixgbe") != NULL)
> > + ret = rte_pmd_ixgbe_set_vf_mac_anti_spoof(res->port_id,
> > + res->vf_id,
> > + is_on);
> > switch (ret) {
> > case 0:
> > break;
> > @@ -10982,6 +10995,9 @@ struct cmd_vf_mac_anti_spoof_result {
> > case -ENODEV:
> > printf("invalid port_id %d\n", res->port_id);
> > break;
> > + case -ENOTSUP:
> > + printf("function not implemented\n");
> > + break;
> > default:
> > printf("programming error: (%s)\n", strerror(-ret));
> > }
> > @@ -11053,10 +11069,15 @@ struct cmd_vf_vlan_stripq_result {
> > __attribute__((unused)) void *data)
> > {
> > struct cmd_vf_vlan_stripq_result *res = parsed_result;
> > - int ret = 0;
> > + int ret = -ENOTSUP;
> > int is_on = (strcmp(res->on_off, "on") == 0) ? 1 : 0;
> > + struct rte_eth_dev_info dev_info;
> >
> > - ret = rte_pmd_ixgbe_set_vf_vlan_stripq(res->port_id, res->vf_id,
> > is_on);
> > + rte_eth_dev_info_get(res->port_id, &dev_info);
> > +
> > + if (strstr(dev_info.driver_name, "ixgbe") != NULL)
> > + ret = rte_pmd_ixgbe_set_vf_vlan_stripq(res->port_id, res-
> > >vf_id,
> > + is_on);
> > switch (ret) {
> > case 0:
> > break;
> > @@ -11066,6 +11087,9 @@ struct cmd_vf_vlan_stripq_result {
> > case -ENODEV:
> > printf("invalid port_id %d\n", res->port_id);
> > break;
> > + case -ENOTSUP:
> > + printf("function not implemented\n");
> > + break;
> > default:
> > printf("programming error: (%s)\n", strerror(-ret));
> > }
> > @@ -11137,9 +11161,14 @@ struct cmd_vf_vlan_insert_result {
> > __attribute__((unused)) void *data)
> > {
> > struct cmd_vf_vlan_insert_result *res = parsed_result;
> > - int ret;
> > + int ret = -ENOTSUP;
> > + struct rte_eth_dev_info dev_info;
> >
> > - ret = rte_pmd_ixgbe_set_vf_vlan_insert(res->port_id, res->vf_id,
> > res->vlan_id);
> > + rte_eth_de
Re: [dpdk-dev] [dpdk-stable] [PATCH] app/testpmd: fix ixgbe private API calling
Hi Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Wednesday, January 11, 2017 3:27 PM > To: Iremonger, Bernard ; Lu, Wenzhuo > ; dev@dpdk.org > Cc: Wu, Jingjing ; sta...@dpdk.org > Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] app/testpmd: fix ixgbe > private API calling > > On 1/11/2017 3:20 PM, Iremonger, Bernard wrote: > > Hi Wenzhuo, > > > > > >>> Subject: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API > >>> calling > >>> > >>> Some ixgbe private APIs are added to expose ixgbe specific functions. > >>> When they're used by testpmd, there's no check for if the NICs are > ixgbe. > >>> Other NICs also have chance to call these APIs. > >>> This patch add the check and the feedback print. > >> > >> I am not sure that testpmd is the right place to do this. > >> The rte_pmd_ixgbe_* functions are public API's which can be called by > >> other applications. > >> The checks should be in the rte_pmd_ixgbe_* API's > > > > It is useful to handle the return code -ENOTSUP in testpmd. > > > > Makes sense, and I think it is good idea to add them in your patch, since it > introduces returning -ENOTSUP, would you mind sending a new version of > your patch with this update? > So we can drop this patch completely. > > Thanks, > ferruh > I don't think this patch should be dropped. Testpmd is already handling -EINVAL and -ENODEV. It makes sense for it to handle -ENOTSUP for the cases in the patch. Regards, Bernard.
Re: [dpdk-dev] [dpdk-stable] [PATCH] app/testpmd: fix ixgbe private API calling
Hi Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Wednesday, January 11, 2017 4:19 PM > To: Iremonger, Bernard ; Lu, Wenzhuo > ; dev@dpdk.org > Cc: Wu, Jingjing ; sta...@dpdk.org > Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] app/testpmd: fix ixgbe > private API calling > > On 1/11/2017 3:47 PM, Iremonger, Bernard wrote: > > Hi Ferruh, > > > >> -Original Message- > >> From: Yigit, Ferruh > >> Sent: Wednesday, January 11, 2017 3:27 PM > >> To: Iremonger, Bernard ; Lu, Wenzhuo > >> ; dev@dpdk.org > >> Cc: Wu, Jingjing ; sta...@dpdk.org > >> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] app/testpmd: fix ixgbe > >> private API calling > >> > >> On 1/11/2017 3:20 PM, Iremonger, Bernard wrote: > >>> Hi Wenzhuo, > >>> > >>> > >>>>> Subject: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API > >>>>> calling > >>>>> > >>>>> Some ixgbe private APIs are added to expose ixgbe specific functions. > >>>>> When they're used by testpmd, there's no check for if the NICs are > >> ixgbe. > >>>>> Other NICs also have chance to call these APIs. > >>>>> This patch add the check and the feedback print. > >>>> > >>>> I am not sure that testpmd is the right place to do this. > >>>> The rte_pmd_ixgbe_* functions are public API's which can be called > >>>> by other applications. > >>>> The checks should be in the rte_pmd_ixgbe_* API's > >>> > >>> It is useful to handle the return code -ENOTSUP in testpmd. > >>> > >> > >> Makes sense, and I think it is good idea to add them in your patch, > >> since it introduces returning -ENOTSUP, would you mind sending a new > >> version of your patch with this update? > >> So we can drop this patch completely. > >> > >> Thanks, > >> ferruh > >> > > I don't think this patch should be dropped. > > Testpmd is already handling -EINVAL and -ENODEV. > > It makes sense for it to handle -ENOTSUP for the cases in the patch. > > This patch adds driver check [1] before ixgbe APIs, since now that check is > done within ixgbe APIs by your patch. Why do we need this patch at all? > > [1] > if (strstr(dev_info.driver_name, "ixgbe") != NULL) I think our lines have got slightly crossed. This patch is doing two things, the check [1] above which is not needed now (after my ixgbe patch). Secondly it is handling the ret code of the rte_pmd_ixgbe_* API's, I think this is useful. Regards, Bernard.
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/ixgbe: fix API parameter checking
Hi Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, January 11, 2017 3:15 PM
> To: Iremonger, Bernard ; dev@dpdk.org;
> Lu, Wenzhuo
> Cc: sta...@dpdk.org
> Subject: Re: [dpdk-stable] [PATCH] net/ixgbe: fix API parameter checking
>
> On 1/11/2017 2:25 PM, Bernard Iremonger wrote:
> > Add checks to rte_pmd_ixgbe_* API's to ensure that the port is an
> > ixgbe port.
> >
> > Fixes: 49e248223e9f ("net/ixgbe: add API for VF management")
> >
> > CC: sta...@dpdk.org
> > Signed-off-by: Bernard Iremonger
> > ---
> > drivers/net/ixgbe/ixgbe_ethdev.c | 71
> > ++--
> > 1 file changed, 69 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index b7ddd4f..ca14104 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -1,7 +1,7 @@
> > /*-
> > * BSD LICENSE
> > *
> > - * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> > + * Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
> > * All rights reserved.
> > *
> > * Redistribution and use in source and binary forms, with or without
> > @@ -4066,6 +4066,12 @@ rte_pmd_ixgbe_set_vf_mac_addr(uint8_t port,
> uint16_t vf,
> > dev = &rte_eth_devices[port];
> > rte_eth_dev_info_get(port, &dev_info);
> >
> > + if (!strstr(dev_info.driver_name, "ixgbe"))
> > + return -ENOTSUP;
> > +
> > + if (strstr(dev_info.driver_name, "ixgbe_vf"))
> > + return -ENOTSUP;
> > +
>
> This part seems common for all functions, what do you think exporting this
> into a static function?
>
> Also in the feature if you need to update the method to decide if this port_id
> is supported or not, only that function will be effected.
>
> <...>
Ok, I will put the checks into a static function and send a v2.
Regards,
Bernard.
Re: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API calling
Hi Wenzhuo, > -Original Message- > From: Lu, Wenzhuo > Sent: Thursday, January 12, 2017 1:09 AM > To: Iremonger, Bernard ; dev@dpdk.org > Cc: Wu, Jingjing ; sta...@dpdk.org > Subject: RE: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API calling > > Hi Bernard, > > > -Original Message- > > From: Iremonger, Bernard > > Sent: Wednesday, January 11, 2017 6:27 PM > > To: Lu, Wenzhuo; dev@dpdk.org > > Cc: Wu, Jingjing; sta...@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API > > calling > > > > Hi Wenzhuo, > > > > > > > -Original Message- > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu > > > Sent: Wednesday, January 11, 2017 2:48 AM > > > To: dev@dpdk.org > > > Cc: Wu, Jingjing ; Lu, Wenzhuo > > > ; sta...@dpdk.org > > > Subject: [dpdk-dev] [PATCH] app/testpmd: fix ixgbe private API > > > calling > > > > > > Some ixgbe private APIs are added to expose ixgbe specific functions. > > > When they're used by testpmd, there's no check for if the NICs are ixgbe. > > > Other NICs also have chance to call these APIs. > > > This patch add the check and the feedback print. > > > > I am not sure that testpmd is the right place to do this. > > The rte_pmd_ixgbe_* functions are public API's which can be called by > > other applications. > > The checks should be in the rte_pmd_ixgbe_* API's > To be safer, it's better to add a check in the APIs. I have already sent a patch for ixgbe which Ferruh has reviewed and applied to dpdk-next-net http://dpdk.org/dev/patchwork/patch/19151/ We should consider doing something similar for the i40e. > But the APIs is so called private API, not really public. Considering if we > have > the same function on different NICs, for example we have rte_pmd_ixgbe_a > and rte_pmd_i40e_a. > APP still need to call them one by one, like ret = rte_pmd_ixgbe_a; ret = > rte_pmd_i40e_a; > > then, why not add the check, like > If (NIC is ixgbe) > ret = rte_pmd_ixgbe_a; > if (NIC is i40e) > ret = rte_pmd_i40e_a; There is already code like the above in testpmd in cases where there is a choice of rte_pmd_* functions to call. > testpmd is an example to let the users to know how to use the APIs. They > should follow the example. > How about your opinion? In the case where there is no choice of function to make. There is no need to check the NIC in testpmd (as it is now done in the rte_pmd_ixgbe_* API's). Regards, Bernard.
Re: [dpdk-dev] [PATCH v3 1/2] net/i40e: fix segmentation fault in close
Hi Jingjing,
> > Subject: [PATCH v3 1/2] net/i40e: fix segmentation fault in close
> >
> > Change the order of releasing the vsi's.
> > Release the vmdq vsi's first, then release the main vsi.
> >
> > Fixes: 4861cde46116 ("i40e: new poll mode driver")
> >
> > CC: sta...@dpdk.org
> >
> > Signed-off-by: Bernard Iremonger
> > ---
> > drivers/net/i40e/i40e_ethdev.c | 12 +++-
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index f13e61b..e8cfec8 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -2068,18 +2068,17 @@ i40e_dev_close(struct rte_eth_dev *dev)
> > /* shutdown and destroy the HMC */
> > i40e_shutdown_lan_hmc(hw);
> >
> > - /* release all the existing VSIs and VEBs */
> > - i40e_fdir_teardown(pf);
> > - i40e_vsi_release(pf->main_vsi);
> > -
> > for (i = 0; i < pf->nb_cfg_vmdq_vsi; i++) {
> > i40e_vsi_release(pf->vmdq[i].vsi);
> > pf->vmdq[i].vsi = NULL;
> > }
> > -
> > rte_free(pf->vmdq);
> > pf->vmdq = NULL;
> >
> > + /* release all the existing VSIs and VEBs */
> > + i40e_fdir_teardown(pf);
> > + i40e_vsi_release(pf->main_vsi);
> > +
> > /* shutdown the adminq */
> > i40e_aq_queue_shutdown(hw, true);
> > i40e_shutdown_adminq(hw);
> > @@ -4342,6 +4341,9 @@ i40e_vsi_release(struct i40e_vsi *vsi)
> > if (!vsi)
> > return I40E_SUCCESS;
> >
> > + if (!vsi->adapter)
> > + return I40E_ERR_BAD_PTR;
> > +
>
> The change looks fine to me.
> Only minor comments like:
> The dev_close is ethdev level ops, I40E_XX error code need to be replaced
> by The error code defined in ethedev level.
I will replace I40E_ERR_BAD_PTR with -EFAULT in v4.
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v4 2/2] app/testpmd: add command to configure VMDq
Hi Jingjing,
> > Subject: [PATCH v4 2/2] app/testpmd: add command to configure VMDq
> >
> > Add the following command to configure VMDq:
> > port config vmdq
> >
> > Add new command to testpmd user guide.
> >
> > Signed-off-by: Bernard Iremonger
> > ---
> > app/test-pmd/cmdline.c | 60 +
> > app/test-pmd/testpmd.c | 126
> +++-
> > app/test-pmd/testpmd.h | 1 +
> > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 ++
> > 4 files changed, 193 insertions(+), 1 deletion(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > 21d10e4..30969b4 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -629,6 +629,9 @@ static void cmd_help_long_parsed(void
> *parsed_result,
> > " pfc (on|off)\n"
> > "Set the DCB mode.\n\n"
> >
> > + "port config (port_id) vmdq\n"
> > + "Configure VMDq.\n\n"
> > +
> > "port config all burst (value)\n"
> > "Set the number of packets per burst.\n\n"
> >
> > @@ -2322,6 +2325,62 @@ cmdline_parse_inst_t cmd_config_dcb = {
> > },
> > };
> >
> > +/* *** Configure VMDq *** */
> > +struct cmd_config_vmdq {
> > + cmdline_fixed_string_t port;
> > + cmdline_fixed_string_t config;
> > + uint8_t port_id;
> > + cmdline_fixed_string_t vmdq;
> > +};
> > +
> > +static void
> > +cmd_config_vmdq_parsed(void *parsed_result,
> > + __attribute__((unused)) struct cmdline *cl,
> > + __attribute__((unused)) void *data) {
> > + struct cmd_config_vmdq *res = parsed_result;
> > + portid_t port_id = res->port_id;
> > + struct rte_port *port;
> > + int ret;
> > +
> > + port = &ports[port_id];
> > + /** Check if the port is not started **/
> > + if (port->port_status != RTE_PORT_STOPPED) {
> > + printf("Please stop port %d first\n", port_id);
> > + return;
> > + }
> > +
> > + ret = init_port_vmdq_config(port_id);
> > + if (ret != 0) {
> > + printf("Cannot initialize network ports.\n");
> > + return;
> > + }
> > +
> > + cmd_reconfig_device_queue(port_id, 0, 1); }
> I think the device also need to be reconfigured, it should be
> cmd_reconfig_device_queue(port_id, 1, 1);
The device has just been configured by the VMDq command so I think it is ok,
but I will check it.
> > +
> > +cmdline_parse_token_string_t cmd_config_vmdq_port =
> > + TOKEN_STRING_INITIALIZER(struct cmd_config_vmdq, port, "port");
> > +cmdline_parse_token_string_t cmd_config_vmdq_config =
> > + TOKEN_STRING_INITIALIZER(struct cmd_config_vmdq, config,
> "config");
> > +cmdline_parse_token_num_t cmd_config_vmdq_port_id =
> > + TOKEN_NUM_INITIALIZER(struct cmd_config_vmdq, port_id,
> UINT8);
> > +cmdline_parse_token_string_t cmd_config_vmdq_vmdq =
> > + TOKEN_STRING_INITIALIZER(struct cmd_config_vmdq, vmdq,
> "vmdq");
> > +
> > +cmdline_parse_inst_t cmd_config_vmdq = {
> > + .f = cmd_config_vmdq_parsed,
> > + .data = NULL,
> > + .help_str = "port config vmdq",
> > + .tokens = {
> > + (void *)&cmd_config_vmdq_port,
> > + (void *)&cmd_config_vmdq_config,
> > + (void *)&cmd_config_vmdq_port_id,
> > + (void *)&cmd_config_vmdq_vmdq,
> > + NULL,
> > + },
> > +};
> > +
> > /* *** configure number of packets per burst *** */ struct
> cmd_config_burst {
> > cmdline_fixed_string_t port;
> > @@ -12438,6 +12497,7 @@ cmdline_parse_ctx_t main_ctx[] = {
> > (cmdline_parse_inst_t *)&cmd_link_flow_control_set_autoneg,
> > (cmdline_parse_inst_t *)&cmd_priority_flow_control_set,
> > (cmdline_parse_inst_t *)&cmd_config_dcb,
> > + (cmdline_parse_inst_t *)&cmd_config_vmdq,
> > (cmdline_parse_inst_t *)&cmd_read_reg,
> > (cmdline_parse_inst_t *)&cmd_read_reg_bit_field,
> > (cmdline_parse_inst_t *)&cmd_read_reg_bit, diff --git a/app/test-
> > pmd/testpmd.c b/app/test-pmd/testpmd.c index bfb2f8e..11d263d 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -1,7 +1,7 @@
> > /*-
> > * BSD LICENSE
> > *
> > - * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
> > + * Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
> > * All rights reserved.
> > *
> > * Redistribution and use in source and binary forms, with or without
> > @@ -196,6 +196,34 @@ uint8_t dcb_test = 0; queueid_t nb_rxq = 1; /**<
> > Number of RX queues per port. */ queueid_t nb_txq = 1; /**< Number of
> > TX queues per port. */
> >
> > +static const struct rte_eth_conf vmdq_conf_default = {
> > + .rxmode = {
> > + .mq_mode= ETH_MQ_RX_VMDQ_ONLY,
> > + .split_hdr_size = 0,
> > + .header_split = 0, /**< Header Split disabled */
> > + .hw_ip_checksum = 0, /**< IP checksum offload disabled */
> >
Re: [dpdk-dev] [PATCH] net/ixgbe: clean up rte_eth_dev_info_get
Hi Konstantin, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev, > Konstantin > Sent: Wednesday, February 1, 2017 6:10 PM > To: Yigit, Ferruh ; Lu, Wenzhuo > ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: clean up rte_eth_dev_info_get > > > > > -Original Message- > > From: Yigit, Ferruh > > Sent: Wednesday, February 1, 2017 5:40 PM > > To: Ananyev, Konstantin ; Lu, Wenzhuo > > ; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: clean up > > rte_eth_dev_info_get > > > > On 2/1/2017 4:24 PM, Ananyev, Konstantin wrote: > > > Hi Wenzhuo, > > > > > >> -Original Message- > > >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu > > >> Sent: Wednesday, January 25, 2017 2:39 AM > > >> To: dev@dpdk.org > > >> Cc: Lu, Wenzhuo > > >> Subject: [dpdk-dev] [PATCH] net/ixgbe: clean up > > >> rte_eth_dev_info_get > > >> > > >> It'not appropriate to call rte_eth_dev_info_get in PMD, as > > >> rte_eth_dev_info_get need to get info from PMD. > > >> Remove rte_eth_dev_info_get from PMD code and get the info > > >> directly. > > >> > > >> Signed-off-by: Wenzhuo Lu > > >> --- > > >> drivers/net/ixgbe/ixgbe_ethdev.c | 144 > > >> ++- > > >> 1 file changed, 68 insertions(+), 76 deletions(-) > > >> > > >> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c > > >> b/drivers/net/ixgbe/ixgbe_ethdev.c > > >> index 64ce55a..f14a68b 100644 > > >> --- a/drivers/net/ixgbe/ixgbe_ethdev.c > > >> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > > >> @@ -4401,17 +4401,17 @@ static int > ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, > > >> int rar_entry; > > >> uint8_t *new_mac = (uint8_t *)(mac_addr); > > >> struct rte_eth_dev *dev; > > >> -struct rte_eth_dev_info dev_info; > > >> +struct rte_pci_device *pci_dev; > > >> > > >> RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV); > > >> > > >> dev = &rte_eth_devices[port]; > > >> -rte_eth_dev_info_get(port, &dev_info); > > >> +pci_dev = IXGBE_DEV_TO_PCI(dev); > > >> > > >> -if (is_ixgbe_pmd(dev_info.driver_name) != 0) > > >> +if (is_ixgbe_pmd(dev->data->drv_name)) > > >> return -ENOTSUP; > > > > > > I wonder why do we need now that it is really an ixgbe device all over the > place? > > > > This device specific API, so it is missing merits of abstraction > > layer, application can these APIs with any port_id, API should be protected > for it. > > Ah ok, my bad - didn't realize from the patch that it affects only device > specific API :) Would It be too much hassle to move these functions into a > separate file (rte_ixgbe_pmd.c or so)? > Konstantin > > > > > > Konstantin > > > All the device specific API functions are prefixed with rte_pmd_ixgbe so I don't think a separate file is necessary. Regards, Bernard.
Re: [dpdk-dev] [PATCH] net/ixgbe: clean up rte_eth_dev_info_get
Hi Konstantin, > -Original Message- > From: Ananyev, Konstantin > Sent: Friday, February 3, 2017 9:50 AM > To: Iremonger, Bernard ; Yigit, Ferruh > ; Lu, Wenzhuo ; > dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: clean up rte_eth_dev_info_get > > Hi Bernard, > > > -Original Message- > > From: Iremonger, Bernard > > Sent: Friday, February 3, 2017 9:21 AM > > To: Ananyev, Konstantin ; Yigit, Ferruh > > ; Lu, Wenzhuo ; > > dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: clean up > > rte_eth_dev_info_get > > > > Hi Konstantin, > > > > > -Original Message- > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev, > > > Konstantin > > > Sent: Wednesday, February 1, 2017 6:10 PM > > > To: Yigit, Ferruh ; Lu, Wenzhuo > > > ; dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: clean up > > > rte_eth_dev_info_get > > > > > > > > > > > > > -Original Message- > > > > From: Yigit, Ferruh > > > > Sent: Wednesday, February 1, 2017 5:40 PM > > > > To: Ananyev, Konstantin ; Lu, > > > > Wenzhuo ; dev@dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: clean up > > > > rte_eth_dev_info_get > > > > > > > > On 2/1/2017 4:24 PM, Ananyev, Konstantin wrote: > > > > > Hi Wenzhuo, > > > > > > > > > >> -Original Message- > > > > >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo > Lu > > > > >> Sent: Wednesday, January 25, 2017 2:39 AM > > > > >> To: dev@dpdk.org > > > > >> Cc: Lu, Wenzhuo > > > > >> Subject: [dpdk-dev] [PATCH] net/ixgbe: clean up > > > > >> rte_eth_dev_info_get > > > > >> > > > > >> It'not appropriate to call rte_eth_dev_info_get in PMD, as > > > > >> rte_eth_dev_info_get need to get info from PMD. > > > > >> Remove rte_eth_dev_info_get from PMD code and get the info > > > > >> directly. > > > > >> > > > > >> Signed-off-by: Wenzhuo Lu > > > > >> --- > > > > >> drivers/net/ixgbe/ixgbe_ethdev.c | 144 > > > > >> ++- > > > > >> 1 file changed, 68 insertions(+), 76 deletions(-) > > > > >> > > > > >> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c > > > > >> b/drivers/net/ixgbe/ixgbe_ethdev.c > > > > >> index 64ce55a..f14a68b 100644 > > > > >> --- a/drivers/net/ixgbe/ixgbe_ethdev.c > > > > >> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > > > > >> @@ -4401,17 +4401,17 @@ static int > > > ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, > > > > >> int rar_entry; > > > > >> uint8_t *new_mac = (uint8_t *)(mac_addr); > > > > >> struct rte_eth_dev *dev; > > > > >> -struct rte_eth_dev_info dev_info; > > > > >> +struct rte_pci_device *pci_dev; > > > > >> > > > > >> RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV); > > > > >> > > > > >> dev = &rte_eth_devices[port]; > > > > >> -rte_eth_dev_info_get(port, &dev_info); > > > > >> +pci_dev = IXGBE_DEV_TO_PCI(dev); > > > > >> > > > > >> -if (is_ixgbe_pmd(dev_info.driver_name) != 0) > > > > >> +if (is_ixgbe_pmd(dev->data->drv_name)) > > > > >> return -ENOTSUP; > > > > > > > > > > I wonder why do we need now that it is really an ixgbe device > > > > > all over the > > > place? > > > > > > > > This device specific API, so it is missing merits of abstraction > > > > layer, application can these APIs with any port_id, API should be > > > > protected > > > for it. > > > > > > Ah ok, my bad - didn't realize from the patch that it affects only > > > device specific API :) Would It be too much hassle to move these > > > functions into a separate file (rte_ixgbe_pmd.c or so)? > > > Konstantin > > > > > > > > > > > > Konstantin > > > > > > > All the device specific API functions are prefixed with rte_pmd_ixgbe > > That's ok. > > > > so I don't think a separate file is necessary. > > So far I didn't say it is necessary. > Though I think it would be good to group these functions in a separate file to > help avoid confusion (as happened to me) and keep ixgbe_ethdev.c smaller > and cleaner. > Again would be easier to maintain things in future, when more folks will > come up with some extensions for it. > That's why I am asking: would it be a lot of work to do? > It is probably worth doing it now, while we have this API relatively small. > Konstantin > I would need to investigate what is involved in moving the rte_pmd_ixgbe_* functions to a separate file. They may be using some of the static functions and data in the ixgbe_ethdev.c file which could be a problem. The rte_pmd_ixgbe_* functions are considered an "interim solution" until a "generic solution" is agreed. It might be best to postpone this work until the "generic solution" is agreed. Regards, Bernard.
Re: [dpdk-dev] [PATCH v6 2/2] app/testpmd: fix port stop
Hi Jingjing
> -Original Message-
> From: Wu, Jingjing
> Sent: Friday, February 3, 2017 8:22 AM
> To: Iremonger, Bernard ; dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: RE: [PATCH v6 2/2] app/testpmd: fix port stop
>
>
>
> > -Original Message-
> > From: Iremonger, Bernard
> > Sent: Friday, January 27, 2017 6:50 PM
> > To: dev@dpdk.org; Wu, Jingjing
> > Cc: Iremonger, Bernard ;
> sta...@dpdk.org
> > Subject: [PATCH v6 2/2] app/testpmd: fix port stop
> >
> > The rte_eth_dev_stop function is not called if the port_status is not
> > RTE_PORT_STARTED. This can happen if the rte_eth_dev_start function is
> > called directly, ie not through the start_port function.
> >
> > Make sure rte_eth_dev_stop is always called in stop_port function.
> >
> > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> >
> > CC: sta...@dpdk.org
> > Signed-off-by: Bernard Iremonger
> > ---
> > app/test-pmd/testpmd.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > 3d25436..0d7a4d4 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -1490,13 +1490,13 @@ stop_port(portid_t pid)
> > continue;
> > }
> >
> > + rte_eth_dev_stop(pi);
> > +
> > port = &ports[pi];
> > if (rte_atomic16_cmpset(&(port->port_status),
> > RTE_PORT_STARTED,
> > RTE_PORT_HANDLING) == 0)
> > continue;
> >
> > - rte_eth_dev_stop(pi);
> > -
>
> I don't think this fix is correct to move rte_eth_dev_stop above.
>
> We need to make sure rte_eth_dev_start is called in start_port. For vmdq
> configuration, You just need to change the configuration when port is
> stopped.
I think the stop_port() function should always stop the port even if the
port_status is not correct for any reason.
At present stop_port() returns without stopping the port if the port_status is
not RTE_PORT_STARTED.
The VMDq configuration is done whet the port is stopped, however to the
complete the VMDq configuration the port must be started.
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v2 26/32] app/testpmd: initialize receive mode for VMDq
Hi Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Wednesday, December 7, 2016 3:07 PM > To: Lu, Wenzhuo ; dev@dpdk.org > Cc: Iremonger, Bernard > Subject: Re: [dpdk-dev] [PATCH v2 26/32] app/testpmd: initialize receive > mode for VMDq > > On 12/7/2016 3:32 AM, Wenzhuo Lu wrote: > > Initialise VMDq in the init_port_config function in a similar way to > > how it is done in the VMDq sample application. > > What is the effect of doing existing initialization? This patch results in the function i40e_vmdq_setup() function being called in i40e_ethdev.c at Line 1307: ret = i40e_vmdq_setup(dev); We are seeing unexpected side effects from this patch. It will be dropped from the v3 of this patch set, pending further investigation. Regards, Bernard.
Re: [dpdk-dev] [PATCH v2 16/32] net/i40e: add set VF VLAN insert function
Hi Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, December 7, 2016 2:26 PM
> To: Lu, Wenzhuo ; dev@dpdk.org
> Cc: Iremonger, Bernard
> Subject: Re: [dpdk-dev] [PATCH v2 16/32] net/i40e: add set VF VLAN insert
> function
>
> On 12/7/2016 3:31 AM, Wenzhuo Lu wrote:
> > Support inserting VF VLAN id from PF.
> > User can call the API on PF to insert a VLAN id to a specific VF.
>
> Same comment with prev patch, does it make sense to insert " from PF" to
> patch title?
Consistency in the patch titles makes sense.
"set VF VLAN filter from PF" might be better.
> >
> > Signed-off-by: Bernard Iremonger
> > ---
> > drivers/net/i40e/i40e_ethdev.c| 53
> +++
> > drivers/net/i40e/rte_pmd_i40e.h | 19 +++
> > drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> > 3 files changed, 73 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 253209b..c571d8b 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -10361,3 +10361,56 @@ static void i40e_set_default_mac_addr(struct
> rte_eth_dev *dev,
> > else
> > return -EINVAL;
> > }
> > +
> > +int rte_pmd_i40e_set_vf_vlan_insert(uint8_t port, uint16_t vf_id,
> > + uint16_t vlan_id)
> > +{
> > + struct rte_eth_dev *dev;
> > + struct rte_eth_dev_info dev_info;
> > + struct i40e_pf *pf;
> > + struct i40e_pf_vf *vf;
> > + struct i40e_hw *hw;
> > + struct i40e_vsi *vsi;
> > + struct i40e_vsi_context ctxt;
> > + int ret;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port];
> > + rte_eth_dev_info_get(port, &dev_info);
> > +
> > + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> > + hw = I40E_PF_TO_HW(pf);
> > +
> > + /**
> > +* return -ENODEV if SRIOV not enabled, VF number not configured
> > +* or no queue assigned.
> > +*/
> > + if (!hw->func_caps.sr_iov_1_1 || pf->vf_num == 0 ||
> > + pf->vf_nb_qps == 0)
> > + return -ENODEV;
> > +
> > + if (vf_id > pf->vf_num)
if (vf_id >= pf->vf_num)
would be better.
> This check was [1] in prev patches:
> [1]
> if (vf_id > pf->vf_num - 1 || !pf->vfs)
if (vf_id >= pf->vf_num || !pf->vfs)
would be better.
>
> > + return -EINVAL;
> > +
> > + if (vlan_id > 4095)
>
> Can there be any define in base driver for this? Or ETH_VLAN_ID_MAX
> perhaps?
ETHER_MAX_VLAN_ID in rte_ether.h should be used .
> > + return -EINVAL;
> > +
> > + vf = &pf->vfs[vf_id];
> > + vsi = vf->vsi;
> > +
> > + vsi->info.valid_sections =
> cpu_to_le16(I40E_AQ_VSI_PROP_VLAN_VALID);
> > + vsi->info.port_vlan_flags |= I40E_AQ_VSI_PVLAN_INSERT_PVID;
> > + vsi->info.pvid = vlan_id;
> > +
>
> --->
> > + memset(&ctxt, 0, sizeof(ctxt));
> > + (void)rte_memcpy(&ctxt.info, &vsi->info, sizeof(vsi->info));
> > + ctxt.seid = vsi->seid;
> > +
> > + hw = I40E_VSI_TO_HW(vsi);
> > + ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
> > + if (ret != I40E_SUCCESS)
> > + PMD_DRV_LOG(ERR, "Failed to update VSI params");
> <-
>
> If Wenzhuo prefers to extract this part into a function, it can be re-used
> here
> too.
>
> <...>
Re: [dpdk-dev] [PATCH v2 19/32] net/i40e: set VF VLAN filter from PF
Hi Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, December 7, 2016 2:46 PM
> To: Lu, Wenzhuo ; dev@dpdk.org
> Cc: Iremonger, Bernard
> Subject: Re: [dpdk-dev] [PATCH v2 19/32] net/i40e: set VF VLAN filter from
> PF
>
> On 12/7/2016 3:32 AM, Wenzhuo Lu wrote:
> > add rte_pmd_i40e_set_vf_vlan_filter API.
> > User can call the API on PF to enable/disable a set of VF's VLAN
> > filters.
> >
> > Signed-off-by: Bernard Iremonger
> > ---
> > drivers/net/i40e/i40e_ethdev.c| 50
> +++
> > drivers/net/i40e/rte_pmd_i40e.h | 22 ++
> > drivers/net/i40e/rte_pmd_i40e_version.map | 1 +
> > 3 files changed, 73 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 601e933..bc96698 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -10516,3 +10516,53 @@ int rte_pmd_i40e_set_vf_vlan_tag(uint8_t
> > port, uint16_t vf_id, uint8_t on)
> >
> > return ret;
> > }
> > +
> > +int rte_pmd_i40e_set_vf_vlan_filter(uint8_t port, uint16_t vlan_id,
> > + uint64_t vf_mask, uint8_t on) {
> <...>
> > +
> > + for (pool_idx = 0;
> > +pool_idx < ETH_64_POOLS && pool_idx < pf->nb_cfg_vmdq_vsi;
> > +pool_idx++) {
> > + if (vf_mask & ((uint64_t)(1ULL << pool_idx))) {
> > + if (on)
> > + ret = i40e_vsi_add_vlan(pf-
> >vmdq[pool_idx].vsi,
> > + vlan_id);
> > + else
> > + ret = i40e_vsi_delete_vlan(
> > + pf->vmdq[pool_idx].vsi, vlan_id);
> > + }
> > + }
> > +
> > + if (ret != I40E_SUCCESS)
> > + PMD_DRV_LOG(ERR, "Failed to set VF VLAN filter, on = %d",
> on);
>
> Since loop not break on error, this will only log the last one, if the error
> is in
> the middle, it is missed.
It would be better to break out of the loop on error.
>
> <...>
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v1 0/5] net/ixgbe: move set VF functions.
Hi Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Friday, December 9, 2016 11:54 AM > To: Iremonger, Bernard ; > thomas.monja...@6wind.com; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v1 0/5] net/ixgbe: move set VF functions. > > On 12/9/2016 11:27 AM, Bernard Iremonger wrote: > > This patchset implements the following deprecation notice: > > [PATCH v1] doc: announce API and ABI change for librte_ether > > > > The following functions from eth_dev_ops have been moved to the ixgbe > > PMD and renamed: > > > > ixgbe_set_pool_rx_mode > > ixgbe_set_pool_rx > > ixgbe_set_pool_tx > > ixgbe_set_pool_vlan_filter > > ixgbe_set_vf_rate_limit > > > > Renamed the functions to the following: > > > > rte_pmd_ixgbe_set_vf_rxmode > > rte_pmd_ixgbe_set_vf_rx > > rte_pmd_ixgbe_set_vf_tx > > rte_pmd_ixgbe_set_vf_vlan_filter > > rte_pmd_ixgbe_set_vf_rate_limit > > > > Testpmd has been modified to use the following functions: > > rte_pmd_ixgbe_set_vf_rxmode > > rte_pmd_ixgbe_set_vf_rate_limit > > > > New testpmd commands have been added to test the following functions: > > rte_pmd_ixgbe_set_vf_rx > > rte_pmd_ixgbe_set_vf_tx > > rte_pmd_ixgbe_set_vf_vlan_filter > > > > The testpmd user guide has been updated for the new commands. > > > > Bernard Iremonger (5): > > net/ixgbe: move set VF functions from the ethdev > > app/testpmd: use ixgbe public functions > > app/testpmd: add command for set VF VLAN filter > > app/testpmd: add command for set VF receive > > app/testpmd: add command for set VF transmit > > > > app/test-pmd/cmdline.c | 270 > +++- > > app/test-pmd/config.c | 31 ++-- > > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 21 +++ > > drivers/net/ixgbe/ixgbe_ethdev.c| 263 > +++ > > drivers/net/ixgbe/rte_pmd_ixgbe.h | 104 +++ > > drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 10 ++ > > 6 files changed, 678 insertions(+), 21 deletions(-) > > > > Why this patchset doesn't remove ethdev updates for these functions? > > ixgbe is the only user for these eth-dev_ops, since code moved to ixgbe > driver, they and relevant rte_eth_xx functions (and deprecation notice) can > be removed in this patchset. Most probably after testpmd updated to > prevent compilation errors. My understanding is that the functions should be copied and reworked before being removed from the ethdev, and that the removal should be done in a separate patch set. Hi Thomas, Could you clarify please. Regards, Bernard.
Re: [dpdk-dev] [PATCH v1 2/5] app/testpmd: use ixgbe public functions
Hi Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Friday, December 9, 2016 11:57 AM
> To: Iremonger, Bernard ;
> thomas.monja...@6wind.com; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1 2/5] app/testpmd: use ixgbe public
> functions
>
> On 12/9/2016 11:27 AM, Bernard Iremonger wrote:
> > Use the the following ixgbe public functions:
> >
> > rte_pmd_ixgbe_set_vf_rate_limit
> > rte_pmd_ixgbe_set_vf_rx
> > rte_pmd_ixgbe_set_vf_rxmode
> > rte_pmd_ixgbe_set_vf_tx
> > rte_pmd_ixgbe_set_vf_vlan_filter
> >
> > Signed-off-by: Bernard Iremonger
>
> <...>
>
> > @@ -2388,23 +2391,11 @@ int
> > set_vf_rate_limit(portid_t port_id, uint16_t vf, uint16_t rate,
> > uint64_t q_msk) {
> > int diag;
> > - struct rte_eth_link link;
> > -
> > - if (q_msk == 0)
> > - return 0;
> >
> > - if (port_id_is_invalid(port_id, ENABLED_WARN))
> > - return 1;
> > - rte_eth_link_get_nowait(port_id, &link);
> > - if (rate > link.link_speed) {
> > - printf("Invalid rate value:%u bigger than link speed: %u\n",
> > - rate, link.link_speed);
> > - return 1;
> > - }
>
> Why these changes required? Isn't only change is location and naming of the
> ...set_vf_rate_limit() ?
This change is a cleanup as the parameter checking is now done in
rte_pmd_ixgbe_set_vf_rate_limit().
It was not possible to test the parameter checking in
rte_pmd_ixgbe_set_vf_rate_limit() if the parameters were checked in the
set_vf_rate_limit() function.
>
> > - diag = rte_eth_set_vf_rate_limit(port_id, vf, rate, q_msk);
> > + diag = rte_pmd_ixgbe_set_vf_rate_limit(port_id, vf, rate, q_msk);
> > if (diag == 0)
> > return diag;
> > - printf("rte_eth_set_vf_rate_limit for port_id=%d failed diag=%d\n",
> > + printf("rte_pmd_ixgbe_set_vf_rate_limit for port_id=%d failed
> > +diag=%d\n",
> > port_id, diag);
> > return diag;
> > }
> >
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v1 3/5] app/testpmd: add command for set VF VLAN filter
Hi Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Friday, December 9, 2016 12:03 PM
> To: Iremonger, Bernard ;
> thomas.monja...@6wind.com; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1 3/5] app/testpmd: add command for set
> VF VLAN filter
>
> On 12/9/2016 11:27 AM, Bernard Iremonger wrote:
> > Add the following command to testpmd:
> > set vf vlan filter
> >
> > Add command to the testpmd user guide.
> >
> > Signed-off-by: Bernard Iremonger
> > ---
>
> <...>
>
> > +
> > +cmdline_parse_inst_t cmd_set_vf_vlan_filter = {
> > + .f = cmd_set_vf_vlan_filter_parsed,
> > + .data = NULL,
> > + .help_str = "set vf vlan filter
> > +",
>
> s//on|off
>
> Only variables should be wrapped with "<>", fixed string with options can be
> used as a|b|c .
>
> similar issues in other testpmd patches.
>
I will fix in a v2.
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v1 0/5] net/ixgbe: move set VF functions.
Hi Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Friday, December 9, 2016 1:05 PM > To: Iremonger, Bernard > Cc: Yigit, Ferruh ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v1 0/5] net/ixgbe: move set VF functions. > > 2016-12-09 12:00, Iremonger, Bernard: > > From: Yigit, Ferruh > > > Why this patchset doesn't remove ethdev updates for these functions? > > > > > > ixgbe is the only user for these eth-dev_ops, since code moved to > > > ixgbe driver, they and relevant rte_eth_xx functions (and > > > deprecation notice) can be removed in this patchset. Most probably > > > after testpmd updated to prevent compilation errors. > > > > My understanding is that the functions should be copied and reworked > before being removed from the ethdev, and that the removal should be > done in a separate patch set. > > > > Hi Thomas, > > > > Could you clarify please. > > It was announced that these functions will be removed, so they can be safely > removed in 17.02, right? Yes, it was announced in 16.11 that these functions will be removed so I believe they can be safely removed in17.02. > In this case, it is a code move: copy, rework and delete in the same patch. > And yes, the deprecation notice must be removed at the same time. I will add the deletes in a v2 of the patchset. Regards, Bernard.
Re: [dpdk-dev] [PATCH v3 9/9] doc: update release notes
Hi Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Monday, December 12, 2016 3:52 PM > To: Iremonger, Bernard ; > thomas.monja...@6wind.com; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 9/9] doc: update release notes > > Hi Bernard, > > On 12/12/2016 1:50 PM, Bernard Iremonger wrote: > > Add release note for removing set VF API's from the ethdev, renaming > > the API's and moving them to the ixgbe PMD. > > Sorry, my bad, I wasn't clear enough. > > I was thinking about updating "Shared Library Versions" section of the > release notes, and increasing the librte_ethdev.so version (from 5 to 6) I > believe new feature section does not require an update. > > If you don't mind I can update library version with previous patch, and you > don't need to send a new version of the patch. Please let me know. Yes, that's fine with me. > > > > Signed-off-by: Bernard Iremonger > > --- > > doc/guides/rel_notes/release_17_02.rst | 20 > > 1 file changed, 20 insertions(+) > > > > diff --git a/doc/guides/rel_notes/release_17_02.rst > > b/doc/guides/rel_notes/release_17_02.rst > > index 3b65038..d30b258 100644 > > --- a/doc/guides/rel_notes/release_17_02.rst > > +++ b/doc/guides/rel_notes/release_17_02.rst > > @@ -38,6 +38,26 @@ New Features > > Also, make sure to start the actual text at the margin. > > > = > > > > +* **Moved five APIs for VF management from the ethdev to the ixgbe > > +PMD.** > > + > > + The following five APIs for VF management from the PF have been > > + removed from the ethdev, renamed and added to the ixgbe PMD:: > > + > > +rte_eth_dev_set_vf_rate_limit > > +rte_eth_dev_set_vf_rx > > +rte_eth_dev_set_vf_rxmode > > +rte_eth_dev_set_vf_tx > > +rte_eth_dev_set_vf_vlan_filter > > + > > + The API's have been renamed to the following:: > > + > > +rte_pmd_ixgbe_set_vf_rate_limit > > +rte_pmd_ixgbe_set_vf_rx > > +rte_pmd_ixgbe_set_vf_rxmode > > +rte_pmd_ixgbe_set_vf_tx > > +rte_pmd_ixgbe_set_vf_vlan_filter > > + > > + The declarations for the API’s can be found in ``rte_pmd_ixgbe.h``. > > > > Resolved Issues > > --- > > Regards, Bernard.
Re: [dpdk-dev] [PATCH v3 6/9] examples/ethtool: use ixgbe public function
Hi Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Monday, December 12, 2016 4:25 PM > To: Iremonger, Bernard ; > thomas.monja...@6wind.com; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 6/9] examples/ethtool: use ixgbe public > function > > On 12/12/2016 1:50 PM, Bernard Iremonger wrote: > > Replace rte_eth_dev_set_vf_rxmode with > rte_pmd_ixgbe_set_vf_rx_mode. > > > > Signed-off-by: Bernard Iremonger > > --- > > examples/ethtool/lib/rte_ethtool.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/examples/ethtool/lib/rte_ethtool.c > b/examples/ethtool/lib/rte_ethtool.c > > index a1f91d4..0e539f7 100644 > > --- a/examples/ethtool/lib/rte_ethtool.c > > +++ b/examples/ethtool/lib/rte_ethtool.c > > @@ -1,7 +1,7 @@ > > /*- > > * BSD LICENSE > > * > > - * Copyright(c) 2010-2015 Intel Corporation. All rights reserved. > > + * Copyright(c) 2010-2016 Intel Corporation. All rights reserved. > > * All rights reserved. > > * > > * Redistribution and use in source and binary forms, with or without > > @@ -36,6 +36,7 @@ > > #include > > #include > > #include > > +#include > > #include "rte_ethtool.h" > > > > #define PKTPOOL_SIZE 512 > > @@ -354,7 +355,7 @@ rte_ethtool_net_set_rx_mode(uint8_t port_id) > > > > /* Set VF vf_rx_mode, VF unsupport status is discard */ > > for (vf = 0; vf < num_vfs; vf++) > > - rte_eth_dev_set_vf_rxmode(port_id, vf, > > + rte_pmd_ixgbe_set_vf_rxmode(port_id, vf, > > Will these cause a build error if IXGBE_PMD is not enabled? Yes, I will send a v4. > > > ETH_VMDQ_ACCEPT_UNTAG, 0); > > > > /* Enable Rx vlan filter, VF unspport status is discard */ > > Regards, Bernard.
Re: [dpdk-dev] [PATCH v4 0/7] net/ixgbe: move set VF functions.
Hi Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Tuesday, December 13, 2016 1:37 PM > To: Iremonger, Bernard ; > thomas.monja...@6wind.com; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4 0/7] net/ixgbe: move set VF functions. > > On 12/13/2016 11:40 AM, Bernard Iremonger wrote: > > This patchset implements the following deprecation notice: > > [PATCH v1] doc: announce API and ABI change for librte_ether > > > > Changes in V4: > > Fixed compile issues when ixgbe PMD is not present. > > Removed duplicate testpmd commands. > > Added cleanup patch for testpmd. > > Updated release note. > > > > Changes in V3: > > Updated LIBABIVER in Makefile in librte_ether patch. > > Updated rte_ethdev.h and ret_ether_version.map in librte_ether patch. > > Squashed deprecation notice patch into librte_ether patch. > > Added release_note patch. > > > > Changes in V2: > > Update testpmd set vf commands help messages. > > Updated ethtool to use the ixgbe public API's. > > Removed the ixgbe_set_pool_* and ixgbe_set_vf_rate_limit functions. > > Removed the rte_eth_dev_set_vf_* API's Removed the deprecation > notice. > > > > Changes in V1: > > The following functions from eth_dev_ops have been moved to the ixgbe > > PMD and renamed: > > > > ixgbe_set_pool_rx_mode > > ixgbe_set_pool_rx > > ixgbe_set_pool_tx > > ixgbe_set_pool_vlan_filter > > ixgbe_set_vf_rate_limit > > > > Renamed the functions to the following: > > > > rte_pmd_ixgbe_set_vf_rxmode > > rte_pmd_ixgbe_set_vf_rx > > rte_pmd_ixgbe_set_vf_tx > > rte_pmd_ixgbe_set_vf_vlan_filter > > rte_pmd_ixgbe_set_vf_rate_limit > > > > Testpmd has been modified to use the following functions: > > rte_pmd_ixgbe_set_vf_rxmode > > rte_pmd_ixgbe_set_vf_rate_limit > > > > New testpmd commands have been added to test the following functions: > > rte_pmd_ixgbe_set_vf_rx > > rte_pmd_ixgbe_set_vf_tx > > rte_pmd_ixgbe_set_vf_vlan_filter > > > > The testpmd user guide has been updated for the new commands. > > > > Bernard Iremonger (7): > > net/ixgbe: move set VF functions from the ethdev > > app/testpmd: use ixgbe public functions > > app/testpmd: cleanup parameter checking > > examples/ethtool: use ixgbe public function > > net/ixgbe: remove static set VF functions > > librte_ether: remove the set VF API's > > doc: update release notes > > > > Series applied to dpdk-next-net/master, thanks. > > Last patch squashed. Thanks. Regards, Bernard.
Re: [dpdk-dev] [PATCH v2 17/32] net/i40e: set VF broadcast mode from PF
Hi Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, December 7, 2016 2:33 PM
> To: Lu, Wenzhuo ; dev@dpdk.org
> Cc: Iremonger, Bernard
> Subject: Re: [dpdk-dev] [PATCH v2 17/32] net/i40e: set VF broadcast mode
> from PF
>
> On 12/7/2016 3:32 AM, Wenzhuo Lu wrote:
> > Support enabling/disabling VF broadcast mode from PF.
> > User can call the API on PF to enable/disable a specific VF's
> > broadcast mode.
> >
> > Signed-off-by: Bernard Iremonger
>
> <...>
>
> > +int rte_pmd_i40e_set_vf_broadcast(uint8_t port, uint16_t vf_id,
> > +uint8_t on) {
> > + struct rte_eth_dev *dev;
> > + struct rte_eth_dev_info dev_info;
> > + struct i40e_pf *pf;
> > + struct i40e_pf_vf *vf;
> > + struct i40e_hw *hw;
> > + int ret;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port];
> > + rte_eth_dev_info_get(port, &dev_info);
> > +
> > + if (vf_id >= dev_info.max_vfs)
> > + return -EINVAL;
> > +
> > + if (on > 1)
> > + return -EINVAL;
> > +
> > + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> > + hw = I40E_PF_TO_HW(pf);
> > +
> > + if (vf_id > pf->vf_num)
>
> if (vf_id > pf->vf_num - 1 || !pf->vfs)
if (vf_id >= pf->vf_num || !pf->vfs)
might be better.
>
> > + return -EINVAL;
> > +
>
> <...>
Regards,
Bernard.
Re: [dpdk-dev] ixgbe-specific bypass functions
Hi Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Monday, December 19, 2016 2:24 PM > To: Iremonger, Bernard > Cc: dev@dpdk.org > Subject: ixgbe-specific bypass functions > > Hi Bernard, > > You moved some VF functions to ixgbe.h. > Do you think we could do the same kind of work to move bypass functions > from ethdev to ixgbe API? > I would see a 2 steps move: > > 1/ in 17.02 > * copy functions in ixgbe.h > * use them in testpmd > * deprecate ethdev functions > > 2/ in 17.05 > * remove bypass functions from ethdev I don't think that I will have time to do step 1 in 17.02 apart from sending the deprecation notice. I will add step 1 and step 2 to the task list for 17.05. Regards, Bernard.
