Re: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some offload
Thanks, Iremonger.
I will reply this patch with a v3 patch.
> -Original Message-
> From: Iremonger, Bernard
> Sent: Thursday, August 2, 2018 5:12 PM
> To: Dai, Wei ; Wu, Jingjing ; Lu,
> Wenzhuo
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some
> offload
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Thursday, August 2, 2018 2:32 AM
> > To: Wu, Jingjing ; Lu, Wenzhuo
> >
> > Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some
> > offload
> >
> > Without this patch, testpmd command to config Rx offload keep_crc
> > would fail and report "Bad argument".
> > This patch aslo fix the command to config the Tx offload mbuf_fast_free.
> >
> > Fixes: 70815c9ecadd ("ethdev: add new offload flag to keep CRC")
> > Fixes: c73a9071877a ("app/testpmd: add commands to test new offload
> > API")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > Tested-by: Yuan Peng
>
> Should have been [PATCH v2] otherwise fine.
>
> Acked-by: Bernard Iremonger
>
Re: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some offload
Hi, Bernard
Thanks for your feedback and guidance.
I have just submitted a v2 patch to include modification on document.
Thanks & Best Regrards
-Wei
> -Original Message-
> From: Iremonger, Bernard
> Sent: Tuesday, July 24, 2018 10:22 PM
> To: Dai, Wei ; Wu, Jingjing ; Lu,
> Wenzhuo ; dev@dpdk.org
> Cc: Dai, Wei ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some
> offload
>
> Hi Wei,
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Tuesday, July 24, 2018 4:45 AM
> > To: Wu, Jingjing ; Lu, Wenzhuo
> > ; dev@dpdk.org
> > Cc: Dai, Wei ; sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some
> > offload
> >
> > Without this patch, testpmd command to config Rx offload keep_crc
> > would fail and report "Bad argument".
> > This patch aslo fix the command to config the Tx offload mbuf_fast_free.
> >
> > Fixes: 70815c9ecadd ("ethdev: add new offload flag to keep CRC")
> > Fixes: c73a9071877a ("app/testpmd: add commands to test new offload
> > API")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 16
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > 5885289..a0ed3a0 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -16665,7 +16665,7 @@ struct
> cmd_config_per_port_rx_offload_result {
> > offload,
> > "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
> >"qinq_strip#outer_ipv4_cksum#macsec_strip#"
> >
> > "header_split#vlan_filter#vlan_extend#jumbo_frame#"
> > - "crc_strip#scatter#timestamp#security");
> > + "crc_strip#scatter#timestamp#security#keep_crc");
> > cmdline_parse_token_string_t
> > cmd_config_per_port_rx_offload_result_on_off =
> > TOKEN_STRING_INITIALIZER
> > (struct cmd_config_per_port_rx_offload_result,
> > @@ -16744,7 +16744,7 @@ struct
> cmd_config_per_port_rx_offload_result {
> > .help_str = "port config rx_offload
> > vlan_strip|ipv4_cksum|"
> >
> > "udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
> > "macsec_strip|header_split|vlan_filter|vlan_extend|"
> > - "jumbo_frame|crc_strip|scatter|timestamp|security "
> > +
> > "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
> > "on|off",
> > .tokens = {
> > (void *)&cmd_config_per_port_rx_offload_result_port,
> > @@ -16794,7 +16794,7 @@ struct
> cmd_config_per_queue_rx_offload_result
> > {
> > offload,
> > "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
> >"qinq_strip#outer_ipv4_cksum#macsec_strip#"
> >
> > "header_split#vlan_filter#vlan_extend#jumbo_frame#"
> > - "crc_strip#scatter#timestamp#security");
> > + "crc_strip#scatter#timestamp#security#keep_crc");
> > cmdline_parse_token_string_t
> > cmd_config_per_queue_rx_offload_result_on_off =
> > TOKEN_STRING_INITIALIZER
> > (struct cmd_config_per_queue_rx_offload_result,
> > @@ -16846,7 +16846,7 @@ struct
> cmd_config_per_queue_rx_offload_result
> > {
> > "vlan_strip|ipv4_cksum|"
> >
> > "udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
> > "macsec_strip|header_split|vlan_filter|vlan_extend|"
> > - "jumbo_frame|crc_strip|scatter|timestamp|security "
> > +
> > "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
> > "on|off",
> > .tokens = {
> > (void *)&cmd_config_per_queue_rx_offload_result_port,
> > @@ -17063,7 +17063,7 @@ struct
> cmd_config_per_port_tx_offload_result {
> >
> > "sctp_cksum#tcp_tso#udp_tso#outer_ipv4_cksum#"
> > "qinq_insert#vxlan_tnl_tso#gre_tnl_tso#"
> > "ipip_tnl_tso#geneve_tnl_tso#macsec_insert#"
> > - "mt_lockfree#multi_segs#fast_free#security");
> > +
> > "mt_lockfree#m
Re: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some offload
Hi, Yuan
How about your test result ?
Thanks a lot!
> -Original Message-
> From: Dai, Wei
> Sent: Thursday, July 19, 2018 8:21 PM
> To: Wu, Jingjing ; yuan.p...@intle.com
> Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> Subject: [PATCH] app/testpmd: fix commands to config some offload
>
> Without this patch, testpmd command to config Rx offload keep_crc would
> fail and report "Bad argument".
> This patch aslo fix the command to config the Tx offload mbuf_fast_free.
>
> Fixes: 70815c9ecadd ("ethdev: add new offload flag to keep CRC")
> Fixes: c73a9071877a ("app/testpmd: add commands to test new offload
> API")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> app/test-pmd/cmdline.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 5885289..a0ed3a0 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -16665,7 +16665,7 @@ struct cmd_config_per_port_rx_offload_result
> {
>offload,
> "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
> "qinq_strip#outer_ipv4_cksum#macsec_strip#"
> "header_split#vlan_filter#vlan_extend#jumbo_frame#"
> -"crc_strip#scatter#timestamp#security");
> +"crc_strip#scatter#timestamp#security#keep_crc");
> cmdline_parse_token_string_t
> cmd_config_per_port_rx_offload_result_on_off =
> TOKEN_STRING_INITIALIZER
> (struct cmd_config_per_port_rx_offload_result,
> @@ -16744,7 +16744,7 @@ struct cmd_config_per_port_rx_offload_result
> {
> .help_str = "port config rx_offload vlan_strip|ipv4_cksum|"
>
> "udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
> "macsec_strip|header_split|vlan_filter|vlan_extend|"
> - "jumbo_frame|crc_strip|scatter|timestamp|security "
> +
> "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
> "on|off",
> .tokens = {
> (void *)&cmd_config_per_port_rx_offload_result_port,
> @@ -16794,7 +16794,7 @@ struct
> cmd_config_per_queue_rx_offload_result {
>offload,
> "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
> "qinq_strip#outer_ipv4_cksum#macsec_strip#"
> "header_split#vlan_filter#vlan_extend#jumbo_frame#"
> -"crc_strip#scatter#timestamp#security");
> +"crc_strip#scatter#timestamp#security#keep_crc");
> cmdline_parse_token_string_t
> cmd_config_per_queue_rx_offload_result_on_off =
> TOKEN_STRING_INITIALIZER
> (struct cmd_config_per_queue_rx_offload_result,
> @@ -16846,7 +16846,7 @@ struct
> cmd_config_per_queue_rx_offload_result {
> "vlan_strip|ipv4_cksum|"
>
> "udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
> "macsec_strip|header_split|vlan_filter|vlan_extend|"
> - "jumbo_frame|crc_strip|scatter|timestamp|security "
> +
> "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
> "on|off",
> .tokens = {
> (void *)&cmd_config_per_queue_rx_offload_result_port,
> @@ -17063,7 +17063,7 @@ struct cmd_config_per_port_tx_offload_result
> {
> "sctp_cksum#tcp_tso#udp_tso#outer_ipv4_cksum#"
> "qinq_insert#vxlan_tnl_tso#gre_tnl_tso#"
> "ipip_tnl_tso#geneve_tnl_tso#macsec_insert#"
> - "mt_lockfree#multi_segs#fast_free#security");
> + "mt_lockfree#multi_segs#mbuf_fast_free#security");
> cmdline_parse_token_string_t
> cmd_config_per_port_tx_offload_result_on_off =
> TOKEN_STRING_INITIALIZER
> (struct cmd_config_per_port_tx_offload_result,
> @@ -17144,7 +17144,7 @@ struct cmd_config_per_port_tx_offload_result
> {
> "sctp_cksum|tcp_tso|udp_tso|outer_ipv4_cksum|"
> "qinq_insert|vxlan_tnl_tso|gre_tnl_tso|"
> "ipip_tnl_tso|geneve_tnl_tso|macsec_insert|"
> - "mt_lockfree|multi_segs|fast_free|security "
> + "mt_lockfree|multi_segs|mbuf_fast_free|security "
> "on|off",
> .tokens
Re: [dpdk-dev] [PATCH v4] net/ixgbe: config VLAN strip on the fly
Hi, Zhang Qi
Thanks for your feedback.
I've just submitted v5 patch to follow your guidance.
> -Original Message-
> From: Zhang, Qi Z
> Sent: Saturday, May 19, 2018 8:19 AM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Ananyev, Konstantin ; Wu, Yanglong
> ; Yigit, Ferruh
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v4] net/ixgbe: config VLAN strip on the fly
>
>
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Saturday, May 19, 2018 12:09 AM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> > ; Zhang, Qi Z ;
> > Wu, Yanglong ; Yigit, Ferruh
> >
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v4] net/ixgbe: config VLAN strip on the fly
> >
> > The old ixgbe_vlan_offload_set() is called by
> > rte_eth_dev_set_vlan_offload() which is meant to config VLAN
> > strip/filter/extend on all queues.
> > This old function is also called by
> > rte_eth_dev_start()/ixgbe_dev_start()
>
> OK, I think this is what we missed in previous patch, good capture, thanks!
>
> > which need support per-queue VALN strip on only parts of queues.
> > So add new function ixgbe_vlan_offload_config() = old
> > ixgbe_vlan_offload_set().
> > New ixgbe_vlan_offload_set = codes to align VLAN strip flags on all
> > queues with port level setting + ixgbe_vlan_offload_configure().
> >
> > Signed-off-by: Wei Dai
> > Signed-off-by: Yanglong Wu
>
> Though the code can be improved to remove some redundant , but I think
> it's not a big deal right now.
> BTW, I think we still need the fixed line, so it will be added during apply.
>
> Fixes: 860a94d3c692 ("net/ixgbe: support VLAN strip per queue offloading in
> VF")
>
> Acked-by: Qi Zhang
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
As 18.05 release is coming soon.
I'd like to submit http://dpdk.org/dev/patchwork/patch/40226/
in reply to yanglong's v2 patch for quick review and validation.
Thanks for your understanding.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dai, Wei
> Sent: Friday, May 18, 2018 11:06 PM
> To: Zhang, Qi Z ; Wu, Yanglong
> ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> per port
>
> > -Original Message-
> > From: Zhang, Qi Z
> > Sent: Friday, May 18, 2018 8:37 PM
> > To: Dai, Wei ; Wu, Yanglong
> > ; dev@dpdk.org
> > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per
> > port
> >
> > Hi Daiwei:
> >
> > > -Original Message-
> > > From: Dai, Wei
> > > Sent: Friday, May 18, 2018 7:07 PM
> > > To: Zhang, Qi Z ; Wu, Yanglong
> > > ; dev@dpdk.org
> > > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> > > per port
> > >
> > > > -Original Message-
> > > > From: Zhang, Qi Z
> > > > Sent: Friday, May 18, 2018 3:46 PM
> > > > To: Wu, Yanglong ; dev@dpdk.org
> > > > Cc: Dai, Wei
> > > > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> > > > per port
> > > >
> > > > > -Original Message-
> > > > > From: Wu, Yanglong
> > > > > Sent: Friday, May 18, 2018 3:24 PM
> > > > > To: dev@dpdk.org
> > > > > Cc: Zhang, Qi Z ; Dai, Wei
> > > > > ; Wu, Yanglong
> > > > > Subject: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> > > > > per port
> > > > >
> > > > > rxq->offload should synchronize with dev_conf
> > > > >
> > > > > Fixes: 860a94d3c692 ("net/ixgbe: support VLAN strip per queue
> > > > > offloading in
> > > > > VF")
> > > > > Signed-off-by: Yanglong Wu
> > > >
> > > > Acked-by: Qi Zhang
> > >
> > > The release date is coming soon.
> > > Sorry, I have to NACK it.
> > > VLAN strip is per-queue feature,
> > > If it is disabled on port level, it still can be enabled on queue level.
> > > So the else branches still should be removed.
> >
> > Remove the else branch will not disable all queues if some queue is
> > enabled at queue configure level, I think this is not user expected.
> > The purpose of i40e_vlan_offload_set here is to disable all queue's
> > vlan strip, though vlan strip is per queue offload and some queue may
> > be enabled at queue configure level, I don't know why we can't disable
> > them in this function.
> >
> > Thanks
> > Qi
>
> As VLAN_STRIP has already been advertised to per-queue offloading on
> ixgbe 82599/X540/X550.
> The else branches will break this per-queue feature.
>
> The issues is from the testpmd command "vlan set strip on "
> Which is meant to enable/disable VLAN_STRIP on whole port on the fly.
> The call stack is as follows:
> rx_vlan_strip_set(portid_t port_id, int on)
> rte_eth_dev_set_vlan_offload(port_id, vlan_offload); //modify
> dev->data->dev_conf.rxmode.offloads
> dev->dev_ops->vlan_offload_set(dev, mask)
> ixgbe_vlan_offload_set(dev, mask)
> ixgbe_vlan_hw_strip_config(struct rte_eth_dev
> *dev)
> ixgbe_vlan_hw_strip_bitmap_set(struct
> rte_eth_dev
> *dev, uint16_t queue, bool on)
>
> As the VLAN_STRIP is per-queue capability, ixgbe_vlan_hw_strip_config()
> only get it from rxq->offloads which hasn't been update in
> rte_eth_dev_set_vlan_offload(port_id, vlan_offload);
>
> And the ixgbe_vlan_offload_set() is also be called by ixgbe_dev_start() which
> is normal called after dev_configure() and queue_setup().
>
> These are 2 different path to config VLAN_STRIP.
> So we can add a function ixgbe_vlan_offload_config() to let them go
> different way as follows:
>
> dev->dev_ops->vlan_offload_set(dev, mask) -> point to new function
> dev->ixgbe_vlan_offload_config()
> ixgbe_vlan_offload_config(dev, mask) {
> if vlan_strip is configured on whole port {
> update dev->data->dev_conf.rxmode.offloads
> update rxq->offloads on all queues
> }
> Ixgbe_vlan_offload_set()
> }
>
> Ixgbe_dev_start()
> ixgbe_vlan_offload_set()
>
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
> -Original Message-
> From: Zhang, Qi Z
> Sent: Friday, May 18, 2018 8:37 PM
> To: Dai, Wei ; Wu, Yanglong
> ; dev@dpdk.org
> Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
>
> Hi Daiwei:
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Friday, May 18, 2018 7:07 PM
> > To: Zhang, Qi Z ; Wu, Yanglong
> > ; dev@dpdk.org
> > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per
> > port
> >
> > > -Original Message-
> > > From: Zhang, Qi Z
> > > Sent: Friday, May 18, 2018 3:46 PM
> > > To: Wu, Yanglong ; dev@dpdk.org
> > > Cc: Dai, Wei
> > > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> > > per port
> > >
> > > > -Original Message-
> > > > From: Wu, Yanglong
> > > > Sent: Friday, May 18, 2018 3:24 PM
> > > > To: dev@dpdk.org
> > > > Cc: Zhang, Qi Z ; Dai, Wei
> > > > ; Wu, Yanglong
> > > > Subject: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per
> > > > port
> > > >
> > > > rxq->offload should synchronize with dev_conf
> > > >
> > > > Fixes: 860a94d3c692 ("net/ixgbe: support VLAN strip per queue
> > > > offloading in
> > > > VF")
> > > > Signed-off-by: Yanglong Wu
> > >
> > > Acked-by: Qi Zhang
> >
> > The release date is coming soon.
> > Sorry, I have to NACK it.
> > VLAN strip is per-queue feature,
> > If it is disabled on port level, it still can be enabled on queue level.
> > So the else branches still should be removed.
>
> Remove the else branch will not disable all queues if some queue is enabled
> at queue configure level, I think this is not user expected.
> The purpose of i40e_vlan_offload_set here is to disable all queue's vlan
> strip,
> though vlan strip is per queue offload and some queue may be enabled at
> queue configure level, I don't know why we can't disable them in this
> function.
>
> Thanks
> Qi
As VLAN_STRIP has already been advertised to per-queue offloading on ixgbe
82599/X540/X550.
The else branches will break this per-queue feature.
The issues is from the testpmd command "vlan set strip on "
Which is meant to enable/disable VLAN_STRIP on whole port on the fly.
The call stack is as follows:
rx_vlan_strip_set(portid_t port_id, int on)
rte_eth_dev_set_vlan_offload(port_id, vlan_offload); //modify
dev->data->dev_conf.rxmode.offloads
dev->dev_ops->vlan_offload_set(dev, mask)
ixgbe_vlan_offload_set(dev, mask)
ixgbe_vlan_hw_strip_config(struct rte_eth_dev
*dev)
ixgbe_vlan_hw_strip_bitmap_set(struct
rte_eth_dev *dev, uint16_t queue, bool on)
As the VLAN_STRIP is per-queue capability, ixgbe_vlan_hw_strip_config() only
get it from rxq->offloads which hasn't been update in
rte_eth_dev_set_vlan_offload(port_id, vlan_offload);
And the ixgbe_vlan_offload_set() is also be called by ixgbe_dev_start() which
is normal called after dev_configure() and queue_setup().
These are 2 different path to config VLAN_STRIP.
So we can add a function ixgbe_vlan_offload_config() to let them go different
way as follows:
dev->dev_ops->vlan_offload_set(dev, mask) -> point to new function
ixgbe_vlan_offload_config()
ixgbe_vlan_offload_config(dev, mask) {
if vlan_strip is configured on whole port {
update dev->data->dev_conf.rxmode.offloads
update rxq->offloads on all queues
}
Ixgbe_vlan_offload_set()
}
Ixgbe_dev_start()
ixgbe_vlan_offload_set()
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
> -Original Message-
> From: Zhang, Qi Z
> Sent: Friday, May 18, 2018 3:46 PM
> To: Wu, Yanglong ; dev@dpdk.org
> Cc: Dai, Wei
> Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
>
> > -Original Message-
> > From: Wu, Yanglong
> > Sent: Friday, May 18, 2018 3:24 PM
> > To: dev@dpdk.org
> > Cc: Zhang, Qi Z ; Dai, Wei ;
> > Wu, Yanglong
> > Subject: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per
> > port
> >
> > rxq->offload should synchronize with dev_conf
> >
> > Fixes: 860a94d3c692 ("net/ixgbe: support VLAN strip per queue
> > offloading in
> > VF")
> > Signed-off-by: Yanglong Wu
>
> Acked-by: Qi Zhang
The release date is coming soon.
Sorry, I have to NACK it.
VLAN strip is per-queue feature,
If it is disabled on port level, it still can be enabled on queue level.
So the else branches still should be removed.
Re: [dpdk-dev] [PATCH] bus/pci: fix error in parsing vfio driver
Give up this patch as there is already a patch
in http://dpdk.org/dev/patchwork/patch/40030/ bus/pci: correct the earlier
strlcpy conversion
> -Original Message-
> From: Dai, Wei
> Sent: Tuesday, May 15, 2018 10:41 PM
> To: Yigit, Ferruh ; Burakov, Anatoly
>
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: [PATCH] bus/pci: fix error in parsing vfio driver
>
> In pci_get_kernel_driver_by_path(), the available memory size of dri_name
> should be strlen(name + 1) + 1, not the size of the pointer (8 bytes), so
> "vfio-pci" is truncated to "vfio-pc"
> ended with number 0.
> This patch fixes it.
>
> Fixes: fe5f777b5383 ("bus/pci: replace strncpy by strlcpy")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> drivers/bus/pci/linux/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c index
> a73ee49..cc6b383 100644
> --- a/drivers/bus/pci/linux/pci.c
> +++ b/drivers/bus/pci/linux/pci.c
> @@ -54,7 +54,7 @@ pci_get_kernel_driver_by_path(const char *filename,
> char *dri_name)
>
> name = strrchr(path, '/');
> if (name) {
> - strlcpy(dri_name, name + 1, sizeof(dri_name));
> + strlcpy(dri_name, name + 1, strlen(name + 1) + 1);
> return 0;
> }
>
> --
> 2.5.5
Re: [dpdk-dev] [PATCH v13] ethdev: new Rx/Tx offloads API
Hi, Thomas
Thanks for your quick feedback.
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, May 14, 2018 8:54 PM
> To: Dai, Wei
> Cc: dev@dpdk.org; Yigit, Ferruh ; Zhang, Qi Z
>
> Subject: Re: [dpdk-dev] [PATCH v13] ethdev: new Rx/Tx offloads API
>
> 14/05/2018 14:00, Wei Dai:
> > --- a/doc/guides/prog_guide/poll_mode_drv.rst
> > +++ b/doc/guides/prog_guide/poll_mode_drv.rst
> > @@ -303,12 +303,12 @@ In the DPDK offload API, offloads are divided
> > into per-port and per-queue offloa
> > * A pure per-port offloading can't be enabled on a queue and disabled on
> another queue at the same time.
> > * A pure per-port offloading must be enabled or disabled on all queues at
> the same time.
> > * Any offloading is per-queue or pure per-port type, but can't be both
> types at same devices.
> > -* A per-port offloading can be enabled or disabled on all queues at the
> same time.
> > -* It is certain that both per-queue and pure per-port offloading are
> per-port type.
> > +* Port capabilities = pre-queue capabilities + pure per-port capabilities.
>
> s/pre/per/
Sorry for the typo error.
>
> > +* Any supported offloading can be enabled on all queues.
> >
> > The different offloads capabilities can be queried using
> ``rte_eth_dev_info_get()``.
> > The ``dev_info->[rt]x_queue_offload_capa`` returned from
> ``rte_eth_dev_info_get()`` includes all per-queue offloading capabilities.
> > -The ``dev_info->[rt]x_offload_capa`` returned from
> ``rte_eth_dev_info_get()`` includes all per-port and per-queue offloading
> capabilities.
> > +The ``dev_info->[rt]x_offload_capa`` returned from
> ``rte_eth_dev_info_get()`` includes all pure per-port and per-queue
> offloading capabilities.
>
> OK
>
>
> > @@ -1556,29 +1558,29 @@ rte_eth_rx_queue_setup(uint16_t port_id,
> uint16_t rx_queue_id,
> > * The local_conf.offloads input to underlying PMD only carries
> > * those offloadings which are only enabled on this queue and
> > * not enabled on all queues.
> > -* The underlying PMD must be aware of this point.
> > */
>
> OK
>
>
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -1067,13 +1067,18 @@ struct rte_eth_dev_info {
> > uint16_t max_vfs; /**< Maximum number of VFs. */
> > uint16_t max_vmdq_pools; /**< Maximum number of VMDq pools. */
> > uint64_t rx_offload_capa;
> > - /**< All RX offload capabilities including all per queue ones */
> > + /**<
> > +* All RX offload capabilities including all per-queue ones.
> > +* Any flag in [rt]x_offload_capa and [rt]x_queue_offload_capa
> > +* of this structure needn't be repeated in rte_eth_[rt]x_queue_setup().
>
> It is confusing. Better to remove this sentence about queue_setup in port
> capa comment.
>
> > +* A flag enabled at port level can't be disabled at queue level.
>
> This one too: it is a comment about port capa, not queue setup.
>
Sorry, I think I have a mistake about your feedback on v12.
Will remove above 2 sentences.
>
> > @@ -1554,9 +1559,7 @@ const char * __rte_experimental
> rte_eth_dev_tx_offload_name(uint64_t offload);
> > *the [rt]x_offload_capa returned from
> rte_eth_dev_infos_get().
> > *Any type of device supported offloading set in the input
> argument
> > *eth_conf->[rt]xmode.offloads to rte_eth_dev_configure() is
> enabled
> > - *on all [RT]x queues and it can't be disabled no matter whether
> > - *it is cleared or set in the input argument [rt]x_conf->offloads
> > - *to rte_eth_[rt]x_queue_setup().
> > + *on all queues and it can't be disabled in
> rte_eth_[rt]x_queue_setup().
>
> OK
>
>
> Missing: we must explain the "no repeat need" and "no disable port offload
> on queue" constraint.
> In the last review, I was suggesting such sentences:
> No need to repeat flags already enabled at port level.
> A flag enabled at port level, cannot be disabled at queue level.
> I think it should go in queue setup comments.
>
> Opinion?
>
Will add this in the comments of queue_setup( ) in rte_ethdev.h
Re: [dpdk-dev] [PATCH v12] ethdev: new Rx/Tx offloads API
Hi, Thomas & Ferruh
Thanks for your feedback.
I agree with your comments and I am working on the latest commit of the repo
dpdk-next-net.
I will submit a new patch to adopt your suggestion.
Please wait for a while ...
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, May 14, 2018 4:37 PM
> To: Dai, Wei
> Cc: dev@dpdk.org; Yigit, Ferruh ; Zhang, Qi Z
>
> Subject: Re: [dpdk-dev] [PATCH v12] ethdev: new Rx/Tx offloads API
>
> Wei Dai,
> Do you agree with my comments?
> Could we have a wording patch to squash in RC3?
>
>
> 10/05/2018 23:39, Thomas Monjalon:
> > Hi,
> >
> > A first general comment: a lot of spaces are still inside parens.
> > You can grep '( )'.
> >
> > 10/05/2018 13:56, Wei Dai:
> > > --- a/doc/guides/prog_guide/poll_mode_drv.rst
> > > +++ b/doc/guides/prog_guide/poll_mode_drv.rst
> > > +A per-queue offloading can be enabled on a queue and disabled on
> another queue at the same time.
> > > +A pure per-port offload is the one supported by device but not
> per-queue type.
> >
> > Another way to say it: pure per-port offloads are not directly
> > advertised but are the port offloads capabilities minus the queue
> capabilities.
> > port capabilities = pure per-port capabilities + queue capabilities
> >
> > > +A pure per-port offloading can't be enabled on a queue and disabled on
> another queue at the same time.
> > > +A pure per-port offloading must be enabled or disabled on all queues at
> the same time.
> > > +Any offloading is per-queue or pure per-port type, but can't be both
> types at same devices.
> > > +A per-port offloading can be enabled or disabled on all queues at the
> same time.
> >
> > This sentence is useless: it says any offload can be setup for the whole
> port.
> >
> > > +It is certain that both per-queue and pure per-port offloading are
> per-port type.
> >
> > This sentence is confusing. I cannot understand it.
> >
> >
> > > The different offloads capabilities can be queried using
> ``rte_eth_dev_info_get()``.
> > > +The dev_info->[rt]x_queue_offload_capa returned from
> ``rte_eth_dev_info_get()`` includes all per-queue offloading capabilities.
> > > +The dev_info->[rt]x_offload_capa returned from
> ``rte_eth_dev_info_get()`` includes all per-port and per-queue offloading
> capabilities.
> >
> > If you want to stick with pure per-port wording, you should say
> > [rt]x_offload_capa is the port capabilities (including pure per-port and
> per-queue).
> >
> >
> > > --- a/lib/librte_ethdev/rte_ethdev.c
> > > +++ b/lib/librte_ethdev/rte_ethdev.c
> > > + /* Any requested offloading must be within its device capabilities
> */
> > > + if ((local_conf.rxmode.offloads & dev_info.rx_offload_capa) !=
> > > + local_conf.rxmode.offloads) {
> > > + ethdev_log(ERR, "ethdev port_id=%d requested Rx offloads "
> > > + "0x%" PRIx64 " doesn't match Rx offloads "
> > > + "capabilities 0x%" PRIx64 " in %s( )\n",
> > > + port_id,
> > > + local_conf.rxmode.offloads,
> > > + dev_info.rx_offload_capa,
> > > + __func__);
> >
> > We could have a comment saying that an error will be returned in next
> version.
> >
> > > + }
> > > + if ((local_conf.txmode.offloads & dev_info.tx_offload_capa) !=
> > > + local_conf.txmode.offloads) {
> > > + ethdev_log(ERR, "ethdev port_id=%d requested Tx offloads "
> > > + "0x%" PRIx64 " doesn't match Tx offloads "
> > > + "capabilities 0x%" PRIx64 " in %s( )\n",
> > > + port_id,
> > > + local_conf.txmode.offloads,
> > > + dev_info.tx_offload_capa,
> > > + __func__);
> >
> > idem
> >
> > > + }
> >
> >
> > > + /*
> > > + * If an offloading has already been enabled in
> > > + * rte_eth_dev_configure(), it has been enabled on all queues,
> > > + * so there is no need to enable it in this queue again.
> > > + * The local_conf.offloads input to underlying PMD only carries
> > > + * those offloadings which are onl
Re: [dpdk-dev] [PATCH v10] ethdev: new Rx/Tx offloads API
Hi, Thomas Thanks for your feedback and guidance. > -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Thursday, May 10, 2018 10:36 AM > To: Dai, Wei > Cc: dev@dpdk.org; Yigit, Ferruh ; Zhang, Qi Z > > Subject: Re: [dpdk-dev] [PATCH v10] ethdev: new Rx/Tx offloads API > > Hi, > > I am checking if this patch comply with goals discussed in the survey: > http://dpdk.org/ml/archives/dev/2018-March/094459.html > > - Allow "forgetting" port offloads in queue offloads setup. > > - An offload enabled at port level, cannot be disabled at queue level. > > - Every queue capabilities must be reported as port capabilities. > > - A capability should be reported at queue level > only if it can be enabled on queue when it is disabled on port level. > > I think some items must be updated in doxygen comments of rte_ethdev.h. > Please could you try to do a v11 for doxygen? I will review it quickly. > > Examples: > > - in queue offloads: > "No need to repeat flags already enabled at port level. >A flag enabled at port level, cannot be disabled at queue > level." > > - in port capabilities: "(include per-queue capabilities)" > > More comments below, thanks. > > > 10/05/2018 02:56, Wei Dai: > > This patch check if a input requested offloading is valid or not. > > Any reuqested offloading must be supported in the device capabilities. > > Any offloading is disabled by default if it is not set in the > > parameter dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and > > [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ). > > If any offloading is enabled in rte_eth_dev_configure( ) by > > application, it is enabled on all queues no matter whether it is > > per-queue or per-port type and no matter whether it is set or cleared > > in [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ). > > If a per-queue offloading hasn't be enabled in rte_eth_dev_configure( > > ), it can be enabled or disabled for individual queue in > > ret_eth_[rt]x_queue_setup( ). > > A new added offloading is the one which hasn't been enabled in > > rte_eth_dev_configure( ) and is reuqested to be enabled in > > rte_eth_[rt]x_queue_setup( ), it must be per-queue type, otherwise > > triger an error log. > > The underlying PMD must be aware that the requested offloadings to PMD > > specific queue_setup( ) function only carries those new added > > offloadings of per-queue type. > > Good summary. > Please forget the whitespace inside the parens. I will remove whitespaces inside the parens. > > > This patch can make above such checking in a common way in rte_ethdev > > layer to avoid same checking in underlying PMD. > > Good > > > --- a/doc/guides/prog_guide/poll_mode_drv.rst > > +++ b/doc/guides/prog_guide/poll_mode_drv.rst > > @@ -297,16 +297,30 @@ Per-Port and Per-Queue Offloads > > ^^^ > > > > In the DPDK offload API, offloads are divided into per-port and per-queue > offloads. > > +A per-queue offloading can be enabled on a queue and disabled on > another queue at the same time. > > +A pure per-port offloading can't be enabled on a queue and disabled on > another queue at the same time. > > +A pure per-port offloading must be enabled or disabled on all queues at > the same time. > > +A per-port offloading can be enabled or disabled on all queues at the > same time. > > What is the difference between pure per-port and per-port here? > Can I add following words to explain more: A pure per-port offloads are those supported by device but not per-queue type. A supported offload can be per-queue or pure per-port, but can't be both types at same device. Any offloadings are per-port type as it can be enabled or disabled on all queues at the same time. > > +It is certain that both per-queue and pure per-port offloading are per-port > type. > > I don't understand this sentence. > Explained above, I just want to divide all offloading into two distinct types: Per-queue and pure per-port. And per-queue + pure per-port = per-port. > > The different offloads capabilities can be queried using > ``rte_eth_dev_info_get()``. > > +The dev_info->[rt]x_queue_offload_capa returned from > ``rte_eth_dev_info_get()`` includes all per-queue offloading capabilities. > > +The dev_info->[rt]x_offload_capa returned from > ``rte_eth_dev_info_get()`` includes all per-port and per-queue offloading > capabilities. > > Yes > > > +Any requested offloading by applicatio
Re: [dpdk-dev] [PATCH v8] ethdev: check Rx/Tx offloads
> -Original Message- > From: Yigit, Ferruh > Sent: Tuesday, May 8, 2018 8:13 PM > To: Dai, Wei ; tho...@monjalon.net; Doherty, Declan > ; linvi...@tuxdriver.com; m...@semihalf.com; > m...@semihalf.com; gtza...@amazon.com; evge...@amazon.com; > ravi1.ku...@amd.com; shepard.sie...@atomicrules.com; > ed.cz...@atomicrules.com; john.mil...@atomicrules.com; > ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com; > jerin.ja...@caviumnetworks.com; maciej.cze...@caviumnetworks.com; > shijith.thot...@cavium.com; ssriniva...@cavium.com; > santosh.shu...@caviumnetworks.com; rahul.lakkire...@chelsio.com; > ohnd...@cisco.com; hyon...@cisco.com; Lu, Wenzhuo > ; Ananyev, Konstantin > ; Xing, Beilei ; > Zhang, Qi Z ; Wang, Xiao W > ; Wu, Jingjing ; > t...@semihalf.com; d...@marvell.com; nsams...@marvell.com; > jianbo@arm.com; adrien.mazarg...@6wind.com; > nelio.laranje...@6wind.com; ys...@mellanox.com; ma...@mellanox.com; > v...@cesnet.cz; alejandro.luc...@netronome.com; > emant.agra...@nxp.com; shreyansh.j...@nxp.com; > hemant.agra...@nxp.com; harish.pa...@cavium.com; > rasesh.m...@cavium.com; asesh.m...@cavium.com; > shahed.sha...@cavium.com; arybche...@solarflare.com; > yongw...@vmware.com; maxime.coque...@redhat.com; > mtetsu...@gmail.com; Bie, Tiwei ; Legacy, Allain > (Wind River) ; Peters, Matt (Wind River) > ; pascal.ma...@6wind.com; Richardson, > Bruce ; gaetan.ri...@6wind.com; Singh, > Jasvinder ; Dumitrescu, Cristian > > Cc: dev@dpdk.org > Subject: Re: [PATCH v8] ethdev: check Rx/Tx offloads > > On 5/8/2018 11:05 AM, Wei Dai wrote: > > This patch check if a input requested offloading is valid or not. > > Any reuqested offloading must be supported in the device capabilities. > > Any offloading is disabled by default if it is not set in the > > parameter dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and > > [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ). > > If any offloading is enabled in rte_eth_dev_configure( ) by > > application, it is enabled on all queues no matter whether it is > > per-queue or per-port type and no matter whether it is set or cleared > > in [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ). > > If a per-queue offloading hasn't be enabled in rte_eth_dev_configure( > > ), it can be enabled or disabled for individual queue in > > ret_eth_[rt]x_queue_setup( ). > > A new added offloading is the one which hasn't been enabled in > > rte_eth_dev_configure( ) and is reuqested to be enabled in > > rte_eth_[rt]x_queue_setup( ), it must be per-queue type, otherwise > > return error. > > The underlying PMD must be aware that the requested offloadings to PMD > > specific queue_setup( ) function only carries those new added > > offloadings of per-queue type. > > > > This patch can make above such checking in a common way in rte_ethdev > > layer to avoid same checking in underlying PMD. > > > > This patch assumes that all PMDs in 18.05-rc2 have already converted > > to offload API defined in 17.11 . It also assumes that all PMDs can > > return correct offloading capabilities in rte_eth_dev_infos_get( ). > > > > In the beginning of [rt]x_queue_setup( ) of underlying PMD, add > > offloads = [rt]xconf->offloads | > > dev->data->dev_conf.[rt]xmode.offloads; to keep same as offload API > > defined in 17.11 to avoid upper application broken due to offload API > > change. > > PMD can use the info that input [rt]xconf->offloads only carry the new > > added per-queue offloads to do some optimization or some code change > > on base of this patch. > > > > Signed-off-by: Wei Dai > > Signed-off-by: Ferruh Yigit > > Signed-off-by: Qi Zhang > > > > --- > > v8: > > Revise PMD codes to comply with offload API in v7 update document > > > > v7: > > Give the maximum freedom for upper application, only minimal checking > > is performed in ethdev layer. > > Only requested specific pure per-queue offloadings are input to > > underlying PMD. > > > > v6: > > No need enable an offload in queue_setup( ) if it has already been > > enabled in dev_configure( ) > > > > v5: > > keep offload settings sent to PMD same as those from application > > > > v4: > > fix a wrong description in git log message. > > > > v3: > > rework according to dicision of offloading API in community > > > > v2: > > add offloads checking in rte_eth_dev_configure( ). > > check if a requested offloading is supported. > > --- > > doc/guides/prog_guide/poll_mode_drv.rst | 26 +++
Re: [dpdk-dev] [PATCH v8] ethdev: check Rx/Tx offloads
Hi, Andrew
See my in-line comments as below.
From: Andrew Rybchenko [mailto:arybche...@solarflare.com]
Sent: Tuesday, May 8, 2018 7:37 PM
To: Dai, Wei ; Yigit, Ferruh ;
tho...@monjalon.net; Doherty, Declan ;
linvi...@tuxdriver.com; m...@semihalf.com; m...@semihalf.com;
gtza...@amazon.com; evge...@amazon.com; ravi1.ku...@amd.com;
shepard.sie...@atomicrules.com; ed.cz...@atomicrules.com;
john.mil...@atomicrules.com; ajit.khapa...@broadcom.com;
somnath.ko...@broadcom.com; jerin.ja...@caviumnetworks.com;
maciej.cze...@caviumnetworks.com; shijith.thot...@cavium.com;
ssriniva...@cavium.com; santosh.shu...@caviumnetworks.com;
rahul.lakkire...@chelsio.com; ohnd...@cisco.com; hyon...@cisco.com; Lu, Wenzhuo
; Ananyev, Konstantin ;
Xing, Beilei ; Zhang, Qi Z ; Wang,
Xiao W ; Wu, Jingjing ;
t...@semihalf.com; d...@marvell.com; nsams...@marvell.com; jianbo@arm.com;
adrien.mazarg...@6wind.com; nelio.laranje...@6wind.com; ys...@mellanox.com;
ma...@mellanox.com; v...@cesnet.cz; alejandro.luc...@netronome.com;
emant.agra...@nxp.com; shreyansh.j...@nxp.com; hemant.agra...@nxp.com;
harish.pa...@cavium.com; rasesh.m...@cavium.com; asesh.m...@cavium.com;
shahed.sha...@cavium.com; yongw...@vmware.com; maxime.coque...@redhat.com;
mtetsu...@gmail.com; Bie, Tiwei ; Legacy, Allain (Wind
River) ; Peters, Matt (Wind River)
; pascal.ma...@6wind.com; Richardson, Bruce
; gaetan.ri...@6wind.com; Singh, Jasvinder
; Dumitrescu, Cristian
Cc: dev@dpdk.org; Ivan Malov
Subject: Re: [PATCH v8] ethdev: check Rx/Tx offloads
On 05/08/2018 01:05 PM, Wei Dai wrote:
This patch check if a input requested offloading is valid or not.
Any reuqested offloading must be supported in the device capabilities.
Any offloading is disabled by default if it is not set in the parameter
dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and
[rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
If any offloading is enabled in rte_eth_dev_configure( ) by application,
it is enabled on all queues no matter whether it is per-queue or
per-port type and no matter whether it is set or cleared in
[rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
If a per-queue offloading hasn't be enabled in rte_eth_dev_configure( ),
it can be enabled or disabled for individual queue in
ret_eth_[rt]x_queue_setup( ).
A new added offloading is the one which hasn't been enabled in
rte_eth_dev_configure( ) and is reuqested to be enabled in
rte_eth_[rt]x_queue_setup( ), it must be per-queue type,
otherwise return error.
The underlying PMD must be aware that the requested offloadings
to PMD specific queue_setup( ) function only carries those
new added offloadings of per-queue type.
This patch can make above such checking in a common way in rte_ethdev
layer to avoid same checking in underlying PMD.
This patch assumes that all PMDs in 18.05-rc2 have already
converted to offload API defined in 17.11 . It also assumes
that all PMDs can return correct offloading capabilities
in rte_eth_dev_infos_get( ).
In the beginning of [rt]x_queue_setup( ) of underlying PMD,
add offloads = [rt]xconf->offloads |
dev->data->dev_conf.[rt]xmode.offloads; to keep same as offload API
defined in 17.11 to avoid upper application broken due to offload
API change.
PMD can use the info that input [rt]xconf->offloads only carry
the new added per-queue offloads to do some optimization or some
code change on base of this patch.
Signed-off-by: Wei Dai
Signed-off-by: Ferruh Yigit
Signed-off-by: Qi Zhang
[...]
diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
index e42d553..fc2b254 100644
--- a/drivers/net/sfc/sfc_ethdev.c
+++ b/drivers/net/sfc/sfc_ethdev.c
@@ -413,14 +413,16 @@ sfc_rx_queue_setup(struct rte_eth_dev *dev, uint16_t
rx_queue_id,
{
struct sfc_adapter *sa = dev->data->dev_private;
int rc;
+ uint64_t offloads;
sfc_log_init(sa, "RxQ=%u nb_rx_desc=%u socket_id=%u",
rx_queue_id, nb_rx_desc, socket_id);
sfc_adapter_lock(sa);
+ offloads = rx_conf->offloads | dev->data->dev_conf.rxmode.offloads;
I'd prefer to see it inside sfc_rx_qinit() function. It would allow to avoid
sfc_rx_qinit() function prototype changes.
[Wei: As rx_conf is a const argument in sfc_rx_queue_setup( ),
rx_conf->offloads can't be updated.
If sfc_rx_qinit( ) function prototype keep unchanged, the dev->data can be
deduced from the
1st argument sa . Andrew, if my code works well, can it be kept here, you
can change it later
in your separate patch, OK ? ]
rc = sfc_rx_qinit(sa, rx_queue_id, nb_rx_desc, socket_id,
- rx_conf, mb_pool);
+ rx_conf, mb_pool, offloads);
if (rc != 0)
goto fail_rx_qinit;
@@ -469,13 +471,16 @@ sfc_tx_queue_setup(struct rte_eth_dev *dev, uint16_t
tx_queue_id,
{
struct sfc_adapter *sa = dev->data->dev_priva
Re: [dpdk-dev] [PATCH v8] ethdev: check Rx/Tx offloads
> -Original Message-
> From: Andrew Rybchenko [mailto:arybche...@solarflare.com]
> Sent: Wednesday, May 9, 2018 1:52 AM
> To: Dai, Wei ; Yigit, Ferruh ;
> tho...@monjalon.net; shah...@mellanox.com; Zhang, Qi Z
>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v8] ethdev: check Rx/Tx offloads
>
> On 05/08/2018 01:10 PM, Wei Dai wrote:
> > This patch check if a input requested offloading is valid or not.
> > Any reuqested offloading must be supported in the device capabilities.
> > Any offloading is disabled by default if it is not set in the
> > parameter dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and
> > [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
> > If any offloading is enabled in rte_eth_dev_configure( ) by
> > application, it is enabled on all queues no matter whether it is
> > per-queue or per-port type and no matter whether it is set or cleared
> > in [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
> > If a per-queue offloading hasn't be enabled in rte_eth_dev_configure(
> > ), it can be enabled or disabled for individual queue in
> > ret_eth_[rt]x_queue_setup( ).
> > A new added offloading is the one which hasn't been enabled in
> > rte_eth_dev_configure( ) and is reuqested to be enabled in
> > rte_eth_[rt]x_queue_setup( ), it must be per-queue type, otherwise
> > return error.
> > The underlying PMD must be aware that the requested offloadings to PMD
> > specific queue_setup( ) function only carries those new added
> > offloadings of per-queue type.
> >
> > This patch can make above such checking in a common way in rte_ethdev
> > layer to avoid same checking in underlying PMD.
> >
> > This patch assumes that all PMDs in 18.05-rc2 have already converted
> > to offload API defined in 17.11 . It also assumes that all PMDs can
> > return correct offloading capabilities in rte_eth_dev_infos_get( ).
> >
> > In the beginning of [rt]x_queue_setup( ) of underlying PMD, add
> > offloads = [rt]xconf->offloads |
> > dev->data->dev_conf.[rt]xmode.offloads; to keep same as offload API
> > defined in 17.11 to avoid upper application broken due to offload API
> > change.
> > PMD can use the info that input [rt]xconf->offloads only carry the new
> > added per-queue offloads to do some optimization or some code change
> > on base of this patch.
> >
> > Signed-off-by: Wei Dai
> > Signed-off-by: Ferruh Yigit
> > Signed-off-by: Qi Zhang
>
> [...]
>
> > diff --git a/lib/librte_ethdev/rte_ethdev.c
> > b/lib/librte_ethdev/rte_ethdev.c index e560524..523a07b 100644
> > --- a/lib/librte_ethdev/rte_ethdev.c
> > +++ b/lib/librte_ethdev/rte_ethdev.c
> > @@ -1139,6 +1139,28 @@ rte_eth_dev_configure(uint16_t port_id,
> uint16_t nb_rx_q, uint16_t nb_tx_q,
> > ETHER_MAX_LEN;
> > }
> >
> > + /* Any requested offloading must be within its device capabilities */
> > + if ((local_conf.rxmode.offloads & dev_info.rx_offload_capa) !=
> > +local_conf.rxmode.offloads) {
> > + RTE_PMD_DEBUG_TRACE("ethdev port_id=%d requested Rx
> offloads "
> > + "0x%" PRIx64 " doesn't match Rx offloads "
> > + "capabilities 0x%" PRIx64 "\n",
> > + port_id,
> > + local_conf.rxmode.offloads,
> > + dev_info.rx_offload_capa);
> > + return -EINVAL;
> > + }
> > + if ((local_conf.txmode.offloads & dev_info.tx_offload_capa) !=
> > +local_conf.txmode.offloads) {
> > + RTE_PMD_DEBUG_TRACE("ethdev port_id=%d requested Tx
> offloads "
> > + "0x%" PRIx64 " doesn't match Tx offloads "
> > + "capabilities 0x%" PRIx64 "\n",
> > + port_id,
> > + local_conf.txmode.offloads,
> > + dev_info.tx_offload_capa);
> > + return -EINVAL;
> > + }
> > +
> > /* Check that device supports requested rss hash functions. */
> > if ((dev_info.flow_type_rss_offloads |
> > dev_conf->rx_adv_conf.rss_conf.rss_hf) != @@ -1504,6
> +1526,39
> > @@ rte_eth_rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id,
> > &local_conf
Re: [dpdk-dev] [PATCH v7 0/2] app/testpmd: add new commands to test new Tx/Rx offloads
Hi, Ferruh Thanks for your feedback. I lost your mail but I can found it in http://dpdk.org/ml/archives/dev/2018-April/096900.html I will update new version of this patch for new offload API in my v8 big patch for ethdev: check offloads. As my command to get offload capablites and configuration return all results on port level and all queues, I'd like to adopt your suggestion to use 'show port ...' I search '.help_str' in app/test-pmd/cmdline.c and find all existed 'port config ...' is for port level configuration. So if it is used to add new commands to enable/disable per-queue offloading, the style will be broken. I'd like to use 'port config on|off ' to enable/disable offloading on all queues. I also would like to use 'port rxq|txq on|off' to enable/disable offloading on a queue. All above my plan want to keep the style of current command and avoid to introduce more commands. Can you agree it ? Thanks & Best Regards -Wei > -Original Message- > From: Dai, Wei > Sent: Tuesday, April 3, 2018 4:58 PM > To: Lu, Wenzhuo ; Wu, Jingjing > > Cc: dev@dpdk.org; Dai, Wei > Subject: [PATCH v7 0/2] app/testpmd: add new commands to test new Tx/Rx > offloads > > Existed testpmd commands can't support per queue offload configuration. > And there are different commands to enable or disable different offloading. > This patch set add following commands to support new Tx/Rx offloading API > test. > > To get Rx offload capability of a port, please run: > testpmd > rx_offload get capability > > To get current Rx offload per queue and per port configuration of a port, > run: > tesstpmd > rx_offload get configuration > > To enable or disable a Rx per port offloading, please run: > testpmd > rx_offload enable|disable per_port vlan_strip|ipv4_cksum|... > > This command will set|clear the associated bit in > dev->dev_conf.rxmode.offloads > for rte_eth_dev_configure and tx_conf->offloads of all Rx queues for > rte_eth_rx_queue_setup( ). > > To enable or disable a Tx per port offloading, please run: > testpmd > rx_offload enable|disable per_queue vlan_strip|ipv4_cksum|... > > > Same commands like "tx_offload ..." are also added to support new Tx > offload API test. > > Signed-off-by: Wei Dai > Acked-by: Jingjing Wu > > --- > v7: >update testpmd document > v6: >reconfig port and queues if offloading is enabled or disabled > v5: >don't depend on enum types defined in rte_ethdev. > v4: >improve testpmd command per port offload to set or clear the port > configuration >and the queue configuration of all queues. > v3: >add enum rte_eth_rx_offload_type and enum rte_eth_tx_offload_type >free memory of port->rx_offloads and port->tx_offloads when testpmd > is existed > v2: >use rte_eth_dev_rx_offload_name() and > rte_eth_dev_tx_offload_name(). >remove static const strings of Rx/Tx offload names. > > > Wei Dai (2): > app/testpmd: add commands to test new Rx offload API > app/testpmd: add commands to test new Tx offload API > > app/test-pmd/cmdline.c | 759 > > app/test-pmd/testpmd.c | 34 +- > app/test-pmd/testpmd.h | 2 + > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 87 > 4 files changed, 878 insertions(+), 4 deletions(-) > > -- > 2.9.5
Re: [dpdk-dev] [PATCH v7] ethdev: check Rx/Tx offloads
Thanks to Shuler and Ferruh for your feedback and guidance.
PMD at least has these 2 options with this patch:
a). If PMD doesn't want to make much more changes, it still can do
"[rt]x_conf->offloads |= dev->data->dev_conf.rxmode.offloads;"
in the beginning of its specific queue_setup( ) and just remove offload
checking (although the checking always pass now) and all
others keep same. In this way, PMDs still comply with the offload APIs
defined in 17.11.
b). PMD also can use the info that only new added queue-level offloads in the
input argument [rt]x_conf->offloads to make some
optimization or other code changes. It may be more efficient than a).
As Ferruh said, only this patch and without relevant change in PMD will cause
application broken,
I will submit v8 patch which will include this patch for ethdev and code
changes in PMDs with above option a and document update.
I'd like include all these changes in only one patch to avoid application
failure if some patches are not applied and some are applied.
PMD maintainers call go on with option b)
Shuler's suggestion to simplify the new added offloads in queue_setup( ) is
better.
I will adopt it in my v8 patch.
> -Original Message-
> From: Shahaf Shuler [mailto:shah...@mellanox.com]
> Sent: Sunday, May 6, 2018 3:00 AM
> To: Dai, Wei ; Thomas Monjalon
> ; Yigit, Ferruh
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v7] ethdev: check Rx/Tx offloads
>
> Hi Ferruh, Dai,
> > Subject: [dpdk-dev] [PATCH v7] ethdev: check Rx/Tx offloads
> >
> > This patch check if a input requested offloading is valid or not.
> > Any reuqested offloading must be supported in the device capabilities.
> > Any offloading is disabled by default if it is not set in the
> > parameter dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and
> > [rt]x_conf-
> > >offloads to rte_eth_[rt]x_queue_setup( ).
> > From application, a pure per-port offloading can't be enabled on any
> > queue if it hasn't been enabled in rte_eth_dev_configure( ).
> > If any offloading is enabled in rte_eth_dev_configure( ) by
> > application, it is enabled on all queues no matter whether it is
> > per-queue or per-port type and no matter whether it is set or cleared
> > in [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
> > The underlying PMD must be aware that the requested offloadings to PMD
> > specific queue_setup( ) function only carries those offloadings only
> > enabled for the queue but not enabled in rte_eth_dev_configure( ) and
> > they are certain per-queue type.
> >
> > This patch can make above such checking in a common way in rte_ethdev
> > layer to avoid same checking in underlying PMD.
> >
> > Signed-off-by: Wei Dai
> > Signed-off-by: Ferruh Yigit
> >
> > ---
> > v7:
> > Give the maximum freedom for upper application, only minimal checking
> > is performed in ethdev layer.
> > Only requested specific pure per-queue offloadings are input to
> > underlying PMD.
> >
> > v6:
> > No need enable an offload in queue_setup( ) if it has already been
> > enabled in dev_configure( )
> >
> > v5:
> > keep offload settings sent to PMD same as those from application
> >
> > v4:
> > fix a wrong description in git log message.
> >
> > v3:
> > rework according to dicision of offloading API in community
> >
> > v2:
> > add offloads checking in rte_eth_dev_configure( ).
> > check if a requested offloading is supported.
> > ---
> > lib/librte_ethdev/rte_ethdev.c | 150
> > +
> > 1 file changed, 150 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_ethdev.c
> > b/lib/librte_ethdev/rte_ethdev.c index e560524..0ad05eb 100644
> > --- a/lib/librte_ethdev/rte_ethdev.c
> > +++ b/lib/librte_ethdev/rte_ethdev.c
> > @@ -1139,6 +1139,28 @@ rte_eth_dev_configure(uint16_t port_id,
> > uint16_t nb_rx_q, uint16_t nb_tx_q,
> > ETHER_MAX_LEN;
> > }
> >
> > + /* Any requested offloading must be within its device capabilities */
> > + if ((local_conf.rxmode.offloads & dev_info.rx_offload_capa) !=
> > +local_conf.rxmode.offloads) {
> > + RTE_PMD_DEBUG_TRACE("ethdev port_id=%d requested Rx
> > offloads "
> > + "0x%" PRIx64 " doesn't match Rx offloads "
> > + "capabilities 0x%" PRIx64 "\n",
> > + port_id,
> > +
Re: [dpdk-dev] [PATCH v4] ethdev: check Rx/Tx offloads
Thanks to Thomas, Ferruh and Zhang Qi for your feedback.
I will rework v5 patch to follow your guidance.
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, April 26, 2018 4:51 PM
> To: Thomas Monjalon
> Cc: Yigit, Ferruh ; Dai, Wei ;
> dev@dpdk.org
> Subject: RE: [PATCH v4] ethdev: check Rx/Tx offloads
>
>
>
> > -Original Message-
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Thursday, April 26, 2018 4:19 PM
> > To: Zhang, Qi Z
> > Cc: Yigit, Ferruh ; Dai, Wei
> > ; dev@dpdk.org
> > Subject: Re: [PATCH v4] ethdev: check Rx/Tx offloads
> >
> > 26/04/2018 09:59, Zhang, Qi Z:
> > >
> > > > -Original Message-
> > > > From: Yigit, Ferruh
> > > > Sent: Thursday, April 26, 2018 1:05 AM
> > > > To: Dai, Wei ; tho...@monjalon.net; Zhang, Qi Z
> > > >
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [PATCH v4] ethdev: check Rx/Tx offloads
> > > >
> > > > On 4/25/2018 12:50 PM, Wei Dai wrote:
> > > > > This patch check if a requested offloading is supported in the
> > > > > device capability.
> > > > > Any offloading is disabled by default if it is not set in
> > > > > rte_eth_dev_configure( ) and rte_eth_[rt]x_queue_setup().
> > > > > A per port offloading can only be enabled in rte_eth_dev_configure().
> > > > > If a per port offloading is sent to rte_eth_[rt]x_queue_setup(
> > > > > ), return error.
> > > > > Only per queue offloading can be sent to
> rte_eth_[rt]x_queue_setup( ).
> > > > > A per queue offloading is enabled only if it is enabled in
> > > > > rte_eth_dev_configure( ) OR if it is enabled in
> > > > > rte_eth_[rt]x_queue_setup( ).
> > > > > If a per queue offloading is enabled in rte_eth_dev_configure(),
> > > > > it can't be disabled in rte_eth_[rt]x_queue_setup( ).
> > > > > If a per queue offloading is disabled in rte_eth_dev_configure(
> > > > > ), it can be enabled or disabled( ) in rte_eth_[rt]x_queue_setup( ).
> > > > >
> > > > > This patch can make such checking in a common way in rte_ethdev
> > > > > layer to avoid same checking in underlying PMD.
> > > >
> > > > Hi Wei,
> > > >
> > > > For clarification, there is existing API for rc1, and there is a
> > > > suggested update in API for rc2. I guess this patch is for
> > > > suggested update
> > in rc2?
> > > >
> > > > > Signed-off-by: Wei Dai
> > > > >
> > > > > ---
> > > > > v4: fix a wrong description in git log message.
> > > > >
> > > > > v3: rework according to dicision of offloading API in community
> > > > >
> > > > > v2: add offloads checking in rte_eth_dev_configure( ).
> > > > > check if a requested offloading is supported.
> > > > > ---
> > > > > lib/librte_ether/rte_ethdev.c | 76
> > > > > +++
> > > > > 1 file changed, 76 insertions(+)
> > > > >
> > > > > diff --git a/lib/librte_ether/rte_ethdev.c
> > > > > b/lib/librte_ether/rte_ethdev.c index f0f53d4..70a7904 100644
> > > > > --- a/lib/librte_ether/rte_ethdev.c
> > > > > +++ b/lib/librte_ether/rte_ethdev.c
> > > > > @@ -1196,6 +1196,28 @@ rte_eth_dev_configure(uint16_t port_id,
> > > > uint16_t nb_rx_q, uint16_t nb_tx_q,
> > > > > ETHER_MAX_LEN;
> > > > > }
> > > > >
> > > > > + /* Any requested offload must be within its device capability */
> > > > > + if ((local_conf.rxmode.offloads & dev_info.rx_offload_capa) !=
> > > > > + local_conf.rxmode.offloads) {
> > > > > + RTE_PMD_DEBUG_TRACE("ethdev port_id=%d requested Rx
> > > > offloads "
> > > > > + "0x%" PRIx64 " doesn't match Rx
> > > > > offloads "
> > > > > + "capability 0x%" PRIx64 "\n",
> > > > > + port_id,
> > > > > + local_conf.rxmode.offloads,
> > > > > +
Re: [dpdk-dev] [PATCH v2] ethdev: check Rx/Tx offloads
Thanks, Thomas and Ferruh I think I can implement v3 for this. > -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Sunday, April 15, 2018 6:37 PM > To: Yigit, Ferruh ; Dai, Wei > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: check Rx/Tx offloads > > 13/04/2018 19:31, Ferruh Yigit: > > On 3/28/2018 9:57 AM, Wei Dai wrote: > > > This patch check if a requested offloading is supported in the > > > device capability. > > > A per port offloading feature should be enabled or disabled at same > > > time in both rte_eth_dev_configure( ) and rte_eth_rx_queue_setup( > > > )/rte_eth_tx_queue_setup( ). > > > This patch check if a per port offloading flag has same > > > configuration in rte_eth_dev_configure( ) and > > > rte_eth_rx_queue_setup( )/rte_eth_tx_queue_setup( ). > > > This patch can make such checking in a common way in rte_ethdev > > > layer to avoid same checking in underlying PMD. > > > > I think it is good idea to move common check to the abstraction layer > > as much as possible. > > > > But for this case we are targeting an API change in rc2, I believe > > better wait that API change for this update. > > I think Wei could implement some filtering of offload flags: > If an offload is already enabled at port level, we can filter out them when > enabling again at queue level. > By removing such repetition in ethdev, before calling the PMD op, the PMD > does not need to bother for offloads enabled twice. >
Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link status on start
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhang, Qi Z
> Sent: Monday, April 2, 2018 10:34 PM
> To: Chas Williams <3ch...@gmail.com>
> Cc: Zhang, Helin ; dev@dpdk.org; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Charles (Chas) Williams
> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link status on
> start
>
>
>
> > -Original Message-
> > From: Chas Williams [mailto:3ch...@gmail.com]
> > Sent: Monday, April 2, 2018 9:57 PM
> > To: Zhang, Qi Z
> > Cc: Zhang, Helin ; dev@dpdk.org; Lu, Wenzhuo
> > ; Ananyev, Konstantin
> > ; Charles (Chas) Williams
> >
> > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link
> > status on start
> >
> > On Mon, Apr 2, 2018 at 9:45 AM, Zhang, Qi Z
> wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Chas Williams [mailto:3ch...@gmail.com]
> > >> Sent: Monday, April 2, 2018 9:38 PM
> > >> To: Zhang, Qi Z
> > >> Cc: Zhang, Helin ; dev@dpdk.org; Lu,
> Wenzhuo
> > >> ; Ananyev, Konstantin
> > >> ; Charles (Chas) Williams
> > >>
> > >> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link
> > >> status on start
> > >>
> > >> On Mon, Apr 2, 2018 at 8:40 AM, Zhang, Qi Z
> > wrote:
> > >> > Hi Williams:
> > >> >
> > >> >> -Original Message-
> > >> >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Chas
> > >> >> Williams
> > >> >> Sent: Saturday, March 31, 2018 1:22 AM
> > >> >> To: Zhang, Helin
> > >> >> Cc: dev@dpdk.org; Lu, Wenzhuo ;
> Ananyev,
> > >> >> Konstantin ; Charles (Chas)
> > >> >> Williams
> > >> >> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link
> > >> >> status on start
> > >> >>
> > >> >> On Fri, Mar 30, 2018 at 12:30 PM, Zhang, Helin
> > >> >>
> > >> >> wrote:
> > >> >> >
> > >> >> >
> > >> >> >> -Original Message-
> > >> >> >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Chas
> > >> >> >> Williams
> > >> >> >> Sent: Wednesday, February 14, 2018 6:56 AM
> > >> >> >> To: dev@dpdk.org
> > >> >> >> Cc: Lu, Wenzhuo; Ananyev, Konstantin; Charles (Chas) Williams
> > >> >> >> Subject: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link
> > >> >> >> status on start
> > >> >> >>
> > >> >> >> From: "Charles (Chas) Williams"
> > >> >> >>
> > >> >> >> dev->data->eth_link isn't updated until the first interrupt.
> > >> >> >> dev->data->If a
> > >> >> >> link is carrier down, then this interrupt may never happen.
> > >> >> >> Before we finished starting the PMD, call
> > >> >> >> ixgbe_dev_link_update() to ensure we
> > >> >> have a valid status.
> > >> >> >>
> > >> >> >> Signed-off-by: Chas Williams
> > >> >> >> ---
> > >> >> >> drivers/net/ixgbe/ixgbe_ethdev.c | 4
> > >> >> >> 1 file changed, 4 insertions(+)
> > >> >> >>
> > >> >> >> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > >> >> >> b/drivers/net/ixgbe/ixgbe_ethdev.c
> > >> >> >> index 37eb668..27d29dc 100644
> > >> >> >> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > >> >> >> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > >> >> >> @@ -2666,6 +2666,8 @@ ixgbe_dev_start(struct rte_eth_dev
> *dev)
> > >> >> >> if (err)
> > >> >> >> goto error;
> > >> >> >>
> > >> >> >> + ixgbe_dev_link_update(dev, 0);
> > >> >> > It is called in rte_eth_dev_start() if lsc is not enabled, and
> > >> >> > it is not needed here to avoid any duplication.
> > >> >> > BTW, did you see any issue or just check the code? Thanks!
> > >> >>
> > >> >> Yes, I see an issue with bonding. If LSC is enabled, then
> > >> >> link_status isn't set until the first interrupt to update the
> > >> >> link status. If a link is down, this interrupt may never happen
> > >> >> result in
> > >> link_status being somewhat undefined.
> > >> >
> > >> > Is your issue only happened on VF?
> > >> > For PF, I saw ixgbe_check_link is called at ixgbe_dev_start, so
> > >> > link status is
> > >> assume be updated.
> > >> > If you think it is just missed in VF, can you implemented this in
> > >> > the similar way
> > >> as PF?
> > >>
> > >> No, I don't believe it's isolated to VF. ixgbe_check_link()
> > >> doesn't update (atomically write) the dev->data->dev_link. After
> > >> .dev_start() finishes, I need the link_status of the adapter to be set.
> > >
> > > I saw dev_link.link_status does be updated.
> > > err = ixgbe_check_link(hw, &speed, &link_up, 0);
> > > if (err)
> > > goto error;
> > > dev->data->dev_link.link_status = link_up;
> >
> > That doesn't fill in link_duplex, link_speed, or link_autoneg.
> > 802.3ad requires that all the ports of the same bonding group have the
> > same speed and duplex. I need to be able to check the speed and the
> > duplex at least (and autoneg as well).
>
> OK, I'm not sure if it is better to call this at rte_eth_dev_start So far we
> have
> below code.
> if (dev->data->dev_conf.intr_conf.lsc == 0) {
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->link_update,
> -ENOTSUP);
> (*dev->dev_ops->link_
Re: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx offloads API
Thanks, Konstantin and Zhang Qi for your feedback and support.
I have talked with Qi and know following:
To avoid packet dropping when FM10K_SRRCTL_BUFFER_CHAINING_EN is not set,
the queue can work with a different mempool which has larger mem buffer size.
For example, SCATTER is enabled on queue 0 with a small mem buffer size of
mempool 0,
And SCATTER is disabled on queue 1 with a large mem buffer size of mempool 1,
Both queues can avoid packet dropping.
Indeed, current fm10k PMD also automatically set FM10K_SRRCTL_BUFFER_CHAINING_EN
If max_rx_pkt_len + 2 * VLAN_TAG_SIZE > mem_buf_size no matter whether SCATTER
is enabled
on queue configuration or not.
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Sunday, April 1, 2018 8:09 PM
> To: Zhang, Qi Z ; Dai, Wei ;
> Wang, Xiao W
> Cc: 'dev@dpdk.org'
> Subject: RE: [dpdk-dev] [PATCH v2 1/2] net/fm10k: convert to new Rx
> offloads API
>
> Hi Qi,
>
> > > > > > >
> > > > > > > Hi Daiwei:
> > > > > > >
> > > > > > > > +static uint64_t fm10k_get_rx_queue_offloads_capa(struct
> > > > > > > > +rte_eth_dev
> > > > > > > > +*dev) {
> > > > > > > > + RTE_SET_USED(dev);
> > > > > > > > +
> > > > > > > > + return (uint64_t)(DEV_RX_OFFLOAD_SCATTER);
> > > > > > > > +}
> > > > > > >
> > > > > > > why per queue rx scattered feature here?
> > > > > > > My understanding is either we use scattered rx function that
> > > > > > > enable this feature for all queues or we use non-scattered
> > > > > > > rx function that disable this feature for all queues, right?
> > > > > >
> > > > > > Checked with Dai Wei offline, fm10k have per queue register
> > > > > > that can be configured to support rx scattered, So it is per queue
> offload.
> > > > >
> > > > > Ok, but these days we have one RX function per device.
> > > > > Looking at fm10k - it clearly has different RX function for
> > > > > scattered and non-scattered case.
> > > > > Yes, HW does support scatter/non-scatter selection per queue,
> > > > > but our SW - doesn't (same for ixgbe and i40e) So how it could
> > > > > be per queue
> > > offload?
> > > >
> > > > We saw the implementation of fm10k is a little bit different with i40e.
> > > > It set per queue register "FM10K_SRRCTL_BUFFER_CHAINING_EN" to
> > > > turn
> > > on multi-seg feature when offload is required.
> > > >
> > > > That means two queues can have different behavior when process a
> > > > packet that exceed the buffer size base on the register setting,
> > > > though we
> > > use the same rx scattered function, so we think this is per queue
> > > feature, is that make sense?
> > >
> > > Ok, suppose we have 2 functions configured.
> > > One with DEV_RX_OFFLOAD_SCATTER is on, second with
> > > DEV_RX_OFFLOAD_SCATTER is off.
> > > So scatter RX function will be selected, but for second queue HW
> > > support will not be enabled, so packets bigger then RX buffer will
> > > be silently dropped by HW, right?
> >
> > Yes according to datasheet
> >
> > Bit FM10K_SRRCTL_BUFFER_CHAINING_EN:
> >
> > 0b = Any packet longer than the data buffer size is terminated with a
> > TOO_BIG error status in Rx descriptor write-back. The remainder of the
> > frame is not posted to host, it is silently dropped.
> > 1b = A packet can be spread over more than one single receive data
> > buffer
> >
>
> Ok, that's a bit unusual approach but understandable.
> Thanks
> Konstantin
Re: [dpdk-dev] [PATCH] net/fm10k: convert to new Rx/Tx offloads API
Thank you, Zhang Qi for your feedback.
> -Original Message-
> From: Zhang, Qi Z
> Sent: Monday, March 19, 2018 11:55 AM
> To: Dai, Wei ; Wang, Xiao W
> Cc: dev@dpdk.org
> Subject: RE: [PATCH] net/fm10k: convert to new Rx/Tx offloads API
>
> Hi Daiwei:
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Friday, March 2, 2018 10:11 PM
> > To: Zhang, Qi Z ; Wang, Xiao W
> >
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH] net/fm10k: convert to new Rx/Tx offloads API
> >
> > Ethdev Rx offloads API has changed since:
> > commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") Ethdev
> > Tx offloads API has changed since:
> > commit cba7f53b717d ("ethdev: introduce Tx queue offloads API") This
> > commit support the new Rx and Tx offloads API.
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/fm10k/fm10k.h | 7 +++
> > drivers/net/fm10k/fm10k_ethdev.c | 33
> > -
> > drivers/net/fm10k/fm10k_rxtx_vec.c | 6 +++---
> > 3 files changed, 34 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
> > index
> > 30dad3e..57bd533 100644
> > --- a/drivers/net/fm10k/fm10k.h
> > +++ b/drivers/net/fm10k/fm10k.h
> > @@ -108,6 +108,11 @@
> >
> > #define FM10K_SIMPLE_TX_FLAG
> > ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
> > ETH_TXQ_FLAGS_NOOFFLOADS)
> > +#define FM10K_SIMPLE_TX_OFFLOADS
> > ((uint64_t)(DEV_TX_OFFLOAD_MULTI_SEGS | \
> > +DEV_TX_OFFLOAD_VLAN_INSERT | \
> > +DEV_TX_OFFLOAD_SCTP_CKSUM | \
> > +DEV_TX_OFFLOAD_UDP_CKSUM | \
> > +DEV_TX_OFFLOAD_TCP_CKSUM))
> >
> > struct fm10k_macvlan_filter_info {
> > uint16_t vlan_num; /* Total VLAN number */
> > @@ -180,6 +185,7 @@ struct fm10k_rx_queue {
> > uint8_t drop_en;
> > uint8_t rx_deferred_start; /* don't start this queue in dev start. */
> > uint16_t rx_ftag_en; /* indicates FTAG RX supported */
> > + uint64_t offloads; /* offloads of DEV_RX_OFFLOAD_* */
> > };
> >
> > /*
> > @@ -212,6 +218,7 @@ struct fm10k_tx_queue {
> > uint16_t next_dd; /* Next pos to check DD flag */
> > volatile uint32_t *tail_ptr;
> > uint32_t txq_flags; /* Holds flags for this TXq */
> > + uint64_t offloads; /* Offloads of DEV_TX_OFFLOAD_* */
> > uint16_t nb_desc;
> > uint16_t port_id;
> > uint8_t tx_deferred_start; /** don't start this queue in dev start.
> > */ diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> > b/drivers/net/fm10k/fm10k_ethdev.c
> > index 9423761..5105874 100644
> > --- a/drivers/net/fm10k/fm10k_ethdev.c
> > +++ b/drivers/net/fm10k/fm10k_ethdev.c
> > @@ -444,7 +444,7 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
> >
> > PMD_INIT_FUNC_TRACE();
> >
> > - if (dev->data->dev_conf.rxmode.hw_strip_crc == 0)
> > + if (dev->data->dev_conf.rxmode.offloads &
> > DEV_RX_OFFLOAD_CRC_STRIP)
> > PMD_INIT_LOG(WARNING, "fm10k always strip CRC");
> > /* multipe queue mode checking */
> > ret = fm10k_check_mq_mode(dev);
> > @@ -454,6 +454,8 @@ fm10k_dev_configure(struct rte_eth_dev *dev)
> > return ret;
> > }
> >
> > + dev->data->scattered_rx = 0;
> > +
> > return 0;
> > }
> >
> > @@ -756,7 +758,7 @@ fm10k_dev_rx_init(struct rte_eth_dev *dev)
> > /* It adds dual VLAN length for supporting dual VLAN */
> > if ((dev->data->dev_conf.rxmode.max_rx_pkt_len +
> > 2 * FM10K_VLAN_TAG_SIZE) > buf_size ||
> > - dev->data->dev_conf.rxmode.enable_scatter) {
> > + rxq->offloads & DEV_RX_OFFLOAD_SCATTER) {
> > uint32_t reg;
> > dev->data->scattered_rx = 1;
> > reg = FM10K_READ_REG(hw, FM10K_SRRCTL(i)); @@
> > -1389,11 +1391,17 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
> > dev_info->vmdq_queue_base= 0;
> > dev_info->max_vmdq_pools = ETH_32_POOLS;
> > dev_info->vmdq_queue_num = FM10K_MAX_QUEUES_PF;
> > + dev_info->rx_queue_offload_capa = DEV_RX_OFFLOAD_SCATTER;
> > dev_info->rx_offload_capa =
> &
Re: [dpdk-dev] [PATCH] ethdev: add enum type for loop on Rx/Tx offloads
Thanks Zhang Qi
> -Original Message-
> From: Zhang, Qi Z
> Sent: Wednesday, March 21, 2018 10:24 PM
> To: Dai, Wei ; Ananyev, Konstantin
> ; tho...@monjalon.net
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] ethdev: add enum type for loop on Rx/Tx
> offloads
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dai, Wei
> > Sent: Wednesday, March 21, 2018 10:09 PM
> > To: Ananyev, Konstantin ;
> > tho...@monjalon.net
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] ethdev: add enum type for loop on
> > Rx/Tx offloads
> >
> > Hi, Konstantin
> > Thanks for your feedback.
> >
> > > -----Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Tuesday, March 20, 2018 8:00 PM
> > > To: Dai, Wei ; tho...@monjalon.net
> > > Cc: dev@dpdk.org; Dai, Wei
> > > Subject: RE: [dpdk-dev] [PATCH] ethdev: add enum type for loop on
> > > Rx/Tx offloads
> > >
> > >
> > > Hi Wei,
> > >
> > > >
> > > > This patch adds enum rte_eth_rx_offload_type and enum
> > > > rte_eth_tx_offload_type. For a loop on all Rx offloads, it is
> > > > convenient to begin with the first enum member
> > > > ETH_RX_OFFLOAD_FIRST_FEATURE and to end at
> > > ETH_RX_OFFLOAD_TOTAL_NUM.
> > > > A loop on all Tx offloads can begin with
> > > ETH_TX_OFFLOAD_FIRST_FEATURE
> > > > and end at ETH_TX_OFFLOAD_TOTAL_NUM.
> > > >
> > > > Signed-off-by: Wei Dai
> > > > ---
> > > > lib/librte_ether/rte_ethdev.h | 44
> > > > +++
> > > > 1 file changed, 44 insertions(+)
> > > >
> > > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > > b/lib/librte_ether/rte_ethdev.h index 0361533..0089ea3 100644
> > > > --- a/lib/librte_ether/rte_ethdev.h
> > > > +++ b/lib/librte_ether/rte_ethdev.h
> > > > @@ -946,6 +946,27 @@ struct rte_eth_conf {
> > > > DEV_RX_OFFLOAD_VLAN_FILTER | \
> > > > DEV_RX_OFFLOAD_VLAN_EXTEND)
> > > >
> > > > +enum rte_eth_rx_offload_type {
> > > > + ETH_RX_OFFLOAD_FIRST_FEATURE = 0,
> > > > + ETH_RX_OFFLOAD_VLAN_STRIP =
> ETH_RX_OFFLOAD_FIRST_FEATURE,
> > > > + ETH_RX_OFFLOAD_IPV4_CKSUM,
> > > > + ETH_RX_OFFLOAD_UDP_CKSUM,
> > > > + ETH_RX_OFFLOAD_TCP_CKSUM,
> > > > + ETH_RX_OFFLOAD_TCP_LRO,
> > > > + ETH_RX_OFFLOAD_QINQ_STRIP,
> > > > + ETH_RX_OFFLOAD_OUTER_IPV4_CKSUM,
> > > > + ETH_RX_OFFLOAD_MACSEC_STRIP,
> > > > + ETH_RX_OFFLOAD_HEADER_SPLIT,
> > > > + ETH_RX_OFFLOAD_VLAN_FILTER,
> > > > + ETH_RX_OFFLOAD_VLAN_EXTEND,
> > > > + ETH_RX_OFFLOAD_JUMBO_FRAME,
> > > > + ETH_RX_OFFLOAD_CRC_STRIP,
> > > > + ETH_RX_OFFLOAD_SCATTER,
> > > > + ETH_RX_OFFLOAD_TIMESTAMP,
> > > > + ETH_RX_OFFLOAD_SECURITY,
> > > > + ETH_RX_OFFLOAD_TOTAL_NUM
> > > > +};
> > > > +
> > > > /*
> > > > * If new Rx offload capabilities are defined, they also must be
> > > > * mentioned in rte_rx_offload_names in rte_ethdev.c file.
> > > > @@ -981,6 +1002,29 @@ struct rte_eth_conf {
> > > > */
> > > > #define DEV_TX_OFFLOAD_SECURITY 0x0002
> > > >
> > > > +enum rte_eth_tx_offload_type {
> > > > + ETH_TX_OFFLOAD_FIRST_FEATURE = 0,
> > > > + ETH_TX_OFFLOAD_VLAN_INSERT =
> > ETH_TX_OFFLOAD_FIRST_FEATURE,
> > > > + ETH_TX_OFFLOAD_IPV4_CKSUM,
> > > > + ETH_TX_OFFLOAD_UDP_CKSUM,
> > > > + ETH_TX_OFFLOAD_TCP_CKSUM,
> > > > + ETH_TX_OFFLOAD_SCTP_CKSUM,
> > > > + ETH_TX_OFFLOAD_TCP_TSO,
> > > > + ETH_TX_OFFLOAD_UDP_TSO,
> > > > + ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM,
> > > > + ETH_TX_OFFLOAD_QINQ_INSERT,
> > > > + ETH_TX_OFFLOAD_VXLAN_TNL_TSO,
> > > > + ETH_TX_OFFLOAD_GRE_TNL_TSO,
> > > > + ETH_TX_OFFLOAD_IPIP_TNL_TSO,
> > > > + ETH_TX_OFFLOAD_GENEVE_TNL_TSO,
> > > > + ETH_TX_OFFLOAD_MACSEC_INSERT,
> > > > + ETH_TX_OFFLOAD_MT_LOCKFREE,
> > > > + ETH_TX_OFFLOAD_MULTI_SEGS,
Re: [dpdk-dev] [PATCH] ethdev: add enum type for loop on Rx/Tx offloads
Hi, Konstantin
Thanks for your feedback.
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, March 20, 2018 8:00 PM
> To: Dai, Wei ; tho...@monjalon.net
> Cc: dev@dpdk.org; Dai, Wei
> Subject: RE: [dpdk-dev] [PATCH] ethdev: add enum type for loop on Rx/Tx
> offloads
>
>
> Hi Wei,
>
> >
> > This patch adds enum rte_eth_rx_offload_type and enum
> > rte_eth_tx_offload_type. For a loop on all Rx offloads, it is
> > convenient to begin with the first enum member
> > ETH_RX_OFFLOAD_FIRST_FEATURE and to end at
> ETH_RX_OFFLOAD_TOTAL_NUM.
> > A loop on all Tx offloads can begin with
> ETH_TX_OFFLOAD_FIRST_FEATURE
> > and end at ETH_TX_OFFLOAD_TOTAL_NUM.
> >
> > Signed-off-by: Wei Dai
> > ---
> > lib/librte_ether/rte_ethdev.h | 44
> > +++
> > 1 file changed, 44 insertions(+)
> >
> > diff --git a/lib/librte_ether/rte_ethdev.h
> > b/lib/librte_ether/rte_ethdev.h index 0361533..0089ea3 100644
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -946,6 +946,27 @@ struct rte_eth_conf {
> > DEV_RX_OFFLOAD_VLAN_FILTER | \
> > DEV_RX_OFFLOAD_VLAN_EXTEND)
> >
> > +enum rte_eth_rx_offload_type {
> > + ETH_RX_OFFLOAD_FIRST_FEATURE = 0,
> > + ETH_RX_OFFLOAD_VLAN_STRIP = ETH_RX_OFFLOAD_FIRST_FEATURE,
> > + ETH_RX_OFFLOAD_IPV4_CKSUM,
> > + ETH_RX_OFFLOAD_UDP_CKSUM,
> > + ETH_RX_OFFLOAD_TCP_CKSUM,
> > + ETH_RX_OFFLOAD_TCP_LRO,
> > + ETH_RX_OFFLOAD_QINQ_STRIP,
> > + ETH_RX_OFFLOAD_OUTER_IPV4_CKSUM,
> > + ETH_RX_OFFLOAD_MACSEC_STRIP,
> > + ETH_RX_OFFLOAD_HEADER_SPLIT,
> > + ETH_RX_OFFLOAD_VLAN_FILTER,
> > + ETH_RX_OFFLOAD_VLAN_EXTEND,
> > + ETH_RX_OFFLOAD_JUMBO_FRAME,
> > + ETH_RX_OFFLOAD_CRC_STRIP,
> > + ETH_RX_OFFLOAD_SCATTER,
> > + ETH_RX_OFFLOAD_TIMESTAMP,
> > + ETH_RX_OFFLOAD_SECURITY,
> > + ETH_RX_OFFLOAD_TOTAL_NUM
> > +};
> > +
> > /*
> > * If new Rx offload capabilities are defined, they also must be
> > * mentioned in rte_rx_offload_names in rte_ethdev.c file.
> > @@ -981,6 +1002,29 @@ struct rte_eth_conf {
> > */
> > #define DEV_TX_OFFLOAD_SECURITY 0x0002
> >
> > +enum rte_eth_tx_offload_type {
> > + ETH_TX_OFFLOAD_FIRST_FEATURE = 0,
> > + ETH_TX_OFFLOAD_VLAN_INSERT = ETH_TX_OFFLOAD_FIRST_FEATURE,
> > + ETH_TX_OFFLOAD_IPV4_CKSUM,
> > + ETH_TX_OFFLOAD_UDP_CKSUM,
> > + ETH_TX_OFFLOAD_TCP_CKSUM,
> > + ETH_TX_OFFLOAD_SCTP_CKSUM,
> > + ETH_TX_OFFLOAD_TCP_TSO,
> > + ETH_TX_OFFLOAD_UDP_TSO,
> > + ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM,
> > + ETH_TX_OFFLOAD_QINQ_INSERT,
> > + ETH_TX_OFFLOAD_VXLAN_TNL_TSO,
> > + ETH_TX_OFFLOAD_GRE_TNL_TSO,
> > + ETH_TX_OFFLOAD_IPIP_TNL_TSO,
> > + ETH_TX_OFFLOAD_GENEVE_TNL_TSO,
> > + ETH_TX_OFFLOAD_MACSEC_INSERT,
> > + ETH_TX_OFFLOAD_MT_LOCKFREE,
> > + ETH_TX_OFFLOAD_MULTI_SEGS,
> > + ETH_TX_OFFLOAD_MBUF_FAST_FREE,
> > + ETH_TX_OFFLOAD_SECURITY,
> > + ETH_TX_OFFLOAD_TOTAL_NUM
> > +};
>
> What is the purpose to introduce these enums?
> It looks like they are not used anywhere?
> Konstantin
When I make the patch for new offloading test with testpmd,
I find I need loop on all possible offloads, without this enum type,
I have to loop from bit 0 to bit 63, I think it is better to stop at the last
one and
No need to bit 63.
I guess it will be helpful for some future application which need loop on all
offloadings.
>
> > +
> > /*
> > * If new Tx offload capabilities are defined, they also must be
> > * mentioned in rte_tx_offload_names in rte_ethdev.c file.
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v2 3/4] net/ixgbe: convert to new Rx offloads API
Hi, Konstantin
Thanks for your patient guidance!
> IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(rxq->reg_idx), srrctl); in
> ixgbe_dev_rx_init( ).
> > Same case is also in the code line: IXGBE_WRITE_REG(hw,
> IXGBE_VFSRRCTL(i), srrctl); in ixgbevf_dev_rx_init( ).
>
> Yes, HW can enable/disable it on a per queue basis.
> Though it affects rx function selection, and as right now we have one rx
> function per device - That's why it looks to me more like a per port offload.
> Though I believe these days ixgbe PMD doesn't support it properly anyway
> (we always set rxd.hdr_addr to zero) - so probably better to remove it at all.
>
Yes, rx function is related with offloading.
I'll remove this header split capability in my next patch set.
> >
> > > > +static int
> > > > +ixgbe_check_rx_queue_offloads(struct rte_eth_dev *dev, uint64_t
> > > > +requested) {
> > > > + uint64_t port_offloads = dev->data->dev_conf.rxmode.offloads;
> > > > + uint64_t queue_supported = ixgbe_get_rx_queue_offloads(dev);
> > > > + uint64_t port_supported = ixgbe_get_rx_port_offloads(dev);
> > > > +
> > > > + if ((requested & (queue_supported | port_supported)) !=
> > > > requested)
> > > > + return 0;
> > > > +
> > > > + if ((port_offloads ^ requested) & port_supported)
> > >
> > > Could you explain a bit more what are you cheking here?
> > > As I can see:
> > > (port_offloads ^ requested) - that's a diff between already set and
> > > newly requested offloads.
> > > Then you check if that diff consists of supported by port offloads,
> > > and if yes you return an error?
> > > Konstantin
> > >
> > This function is similar to mlx4_check_rx_queue_offloads() in mlx4 driver.
> > As the git log message in the commit
> > ce17eddefc20285bbfe575bdc07f42f0b20f34cb say that a per port
> > capability should has same setting (enabling or disabling) on both port
> configuration via rte_eth_dev_configure( ) and queue configuration via
> rte_eth_rx_queue_setup( ).
> > This function check if this requirement is matched or not.
> > It also check offloading request is supported as a per port or a per queue
> capability or not.
> > If above checking is pass, it return 1 else return 0.
>
> Ok, let be more specific here.
> Let say:
> requested == DEV_RX_OFFLOAD_VLAN_STRIP;
> port_offloads == DEV_RX_OFFLOAD_IPV4_CKSUM; port_supported =
> (DEV_RX_OFFLOAD_IPV4_CKSUM |
> DEV_RX_OFFLOAD_UDP_CKSUM |
> DEV_RX_OFFLOAD_TCP_CKSUM |
> DEV_RX_OFFLOAD_CRC_STRIP |
> DEV_RX_OFFLOAD_JUMBO_FRAME |
> DEV_RX_OFFLOAD_SCATTER);
>
> (port_offloads ^ requested) == DEV_RX_OFFLOAD_VLAN_STRIP |
> DEV_RX_OFFLOAD_IPV4_CKSUM; (port_offloads ^ requested) &
> port_supported == DEV_RX_OFFLOAD_IPV4_CKSUM; And that function will
> return failure, while as I understand it shouldn't - requested queue offload
> is
> valid.
>
> Konstantin
I'd like to list the git message of commit
ce17eddefc20285bbfe575bdc07f42f0b20f34cb which
has been submitted by Shahaf Shuler and already been accepted.
SHA-1: ce17eddefc20285bbfe575bdc07f42f0b20f34cb
* ethdev: introduce Rx queue offloads API
Introduce a new API to configure Rx offloads.
In the new API, offloads are divided into per-port and per-queue
offloads. The PMD reports capability for each of them.
Offloads are enabled using the existing DEV_RX_OFFLOAD_* flags.
To enable per-port offload, the offload should be set on both device
configuration and queue configuration. To enable per-queue offload, the
offloads can be set only on queue configuration.
Applications should set the ignore_offload_bitfield bit on rxmode
structure in order to move to the new API.
The old Rx offloads API is kept for the meanwhile, in order to enable a
smooth transition for PMDs and application to the new API.
Signed-off-by: Shahaf Shuler
Reviewed-by: Andrew Rybchenko
Acked-by: Konstantin Ananyev
In your example, IPV4_CKSUM is a per port offloading, it is
Enabled in port_offloads to rte_eth_dev_configure(), and it
Should also be enabled in requested to rte_eth_rx_queue_setup( ).
So your example fails in this checking.
This function is very similar with priv_is_rx_queue_offloads_allowed( ) in
/net/mlx5/mlx5_rxq.c
In the patch http://dpdk.org/dev/patchwork/patch/33386/ which has already been
accepted.
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: add enum type for loop on Rx/Tx offloads
Hi Zhang Qi
Thanks for your feedback.
> -Original Message-
> From: Zhang, Qi Z
> Sent: Monday, March 19, 2018 10:06 PM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Wu, Jingjing
> Cc: dev@dpdk.org; Dai, Wei
> Subject: RE: [dpdk-dev] [PATCH v4 1/3] ethdev: add enum type for loop on
> Rx/Tx offloads
>
> Hi Daiwei:
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Monday, March 19, 2018 8:41 PM
> > To: Lu, Wenzhuo ; Wu, Jingjing
> >
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [dpdk-dev] [PATCH v4 1/3] ethdev: add enum type for loop on
> > Rx/Tx offloads
> >
> > This patch adds enum rte_eth_rx_offload_type and enum
> > rte_eth_tx_offload_type. For a loop on all Rx offloads, it is
> > convenient to begin with the first enum member
> > ETH_RX_OFFLOAD_FIRST_FEATURE and to end at
> ETH_RX_OFFLOAD_TOTAL_NUM.
> > A loop on all Tx offloads can begin with
> ETH_TX_OFFLOAD_FIRST_FEATURE
> > and end at ETH_TX_OFFLOAD_TOTAL_NUM.
> >
> > Signed-off-by: Wei Dai
> > ---
> > lib/librte_ether/rte_ethdev.h | 44
> > +++
> > 1 file changed, 44 insertions(+)
> >
> > diff --git a/lib/librte_ether/rte_ethdev.h
> > b/lib/librte_ether/rte_ethdev.h index 0361533..0089ea3 100644
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -946,6 +946,27 @@ struct rte_eth_conf {
> > DEV_RX_OFFLOAD_VLAN_FILTER | \
> > DEV_RX_OFFLOAD_VLAN_EXTEND)
> >
> > +enum rte_eth_rx_offload_type {
> > + ETH_RX_OFFLOAD_FIRST_FEATURE = 0,
> > + ETH_RX_OFFLOAD_VLAN_STRIP = ETH_RX_OFFLOAD_FIRST_FEATURE,
> > + ETH_RX_OFFLOAD_IPV4_CKSUM,
> > + ETH_RX_OFFLOAD_UDP_CKSUM,
> > + ETH_RX_OFFLOAD_TCP_CKSUM,
> > + ETH_RX_OFFLOAD_TCP_LRO,
> > + ETH_RX_OFFLOAD_QINQ_STRIP,
> > + ETH_RX_OFFLOAD_OUTER_IPV4_CKSUM,
> > + ETH_RX_OFFLOAD_MACSEC_STRIP,
> > + ETH_RX_OFFLOAD_HEADER_SPLIT,
> > + ETH_RX_OFFLOAD_VLAN_FILTER,
> > + ETH_RX_OFFLOAD_VLAN_EXTEND,
> > + ETH_RX_OFFLOAD_JUMBO_FRAME,
> > + ETH_RX_OFFLOAD_CRC_STRIP,
> > + ETH_RX_OFFLOAD_SCATTER,
> > + ETH_RX_OFFLOAD_TIMESTAMP,
> > + ETH_RX_OFFLOAD_SECURITY,
> > + ETH_RX_OFFLOAD_TOTAL_NUM
> > +};
>
> This looks a little duplicate with rte_rx_offload_names in rte_ethdev.c
rte_rx_offload_names is a static string array defined in rte_ethdev.c, if it
can be referred by other files,
the "static" must be removed.
>
> In patch 2/3 and 3/3, I think if you simply loop from offload bit 0 to bit 63
> to
> check the name, that should still work right?
> then this patch could be unnecessary.
Yes, using loop from bit 0 to bit 63 in patch 2/3 and 3/3 can work right.
But I think this enum type is still useful for other application which need to
loop on
all possible offloads.
I will submit this patch as a standalone one and using loop from bit 0 to bit
63 in next version of patch set.
> Regards
> Qi
> > +
> > /*
> > * If new Rx offload capabilities are defined, they also must be
> > * mentioned in rte_rx_offload_names in rte_ethdev.c file.
> > @@ -981,6 +1002,29 @@ struct rte_eth_conf {
> > */
> > #define DEV_TX_OFFLOAD_SECURITY 0x0002
> >
> > +enum rte_eth_tx_offload_type {
> > + ETH_TX_OFFLOAD_FIRST_FEATURE = 0,
> > + ETH_TX_OFFLOAD_VLAN_INSERT = ETH_TX_OFFLOAD_FIRST_FEATURE,
> > + ETH_TX_OFFLOAD_IPV4_CKSUM,
> > + ETH_TX_OFFLOAD_UDP_CKSUM,
> > + ETH_TX_OFFLOAD_TCP_CKSUM,
> > + ETH_TX_OFFLOAD_SCTP_CKSUM,
> > + ETH_TX_OFFLOAD_TCP_TSO,
> > + ETH_TX_OFFLOAD_UDP_TSO,
> > + ETH_TX_OFFLOAD_OUTER_IPV4_CKSUM,
> > + ETH_TX_OFFLOAD_QINQ_INSERT,
> > + ETH_TX_OFFLOAD_VXLAN_TNL_TSO,
> > + ETH_TX_OFFLOAD_GRE_TNL_TSO,
> > + ETH_TX_OFFLOAD_IPIP_TNL_TSO,
> > + ETH_TX_OFFLOAD_GENEVE_TNL_TSO,
> > + ETH_TX_OFFLOAD_MACSEC_INSERT,
> > + ETH_TX_OFFLOAD_MT_LOCKFREE,
> > + ETH_TX_OFFLOAD_MULTI_SEGS,
> > + ETH_TX_OFFLOAD_MBUF_FAST_FREE,
> > + ETH_TX_OFFLOAD_SECURITY,
> > + ETH_TX_OFFLOAD_TOTAL_NUM
> > +};
> > +
> > /*
> > * If new Tx offload capabilities are defined, they also must be
> > * mentioned in rte_tx_offload_names in rte_ethdev.c file.
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH 4/4] net/ixgbe: convert to new Tx offloads API
Hi, Konstantin
Thanks for your feedback.
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, March 15, 2018 7:19 AM
> To: Dai, Wei ; Lu, Wenzhuo
> Cc: dev@dpdk.org
> Subject: RE: [PATCH 4/4] net/ixgbe: convert to new Tx offloads API
>
>
> > diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h
> > b/drivers/net/ixgbe/ixgbe_rxtx.h index 30095fa..d7f0535 100644
> > --- a/drivers/net/ixgbe/ixgbe_rxtx.h
> > +++ b/drivers/net/ixgbe/ixgbe_rxtx.h
> > @@ -223,6 +223,7 @@ struct ixgbe_tx_queue {
> > uint8_t hthresh; /**< Host threshold register. */
> > uint8_t wthresh; /**< Write-back threshold reg.
> */
> > uint32_t txq_flags; /**< Holds flags for this TXq */
> > + uint64_t offloads; /**< Tx offload flags of DEV_TX_OFFLOAD_* */
> > uint32_tctx_curr; /**< Hardware context states.
> */
> > /** Hardware context0 history. */
> > struct ixgbe_advctx_info ctx_cache[IXGBE_CTX_NUM]; @@ -254,6
> +255,12
> > @@ struct ixgbe_txq_ops { #define IXGBE_SIMPLE_FLAGS
> > ((uint32_t)ETH_TXQ_FLAGS_NOMULTSEGS | \
> > ETH_TXQ_FLAGS_NOOFFLOADS)
> >
> > +#define IXGBE_SIMPLE_TX_OFFLOAD_FLAGS
> ((uint64_t)DEV_TX_OFFLOAD_MULTI_SEGS |\
> > + DEV_TX_OFFLOAD_VLAN_INSERT |\
> > + DEV_TX_OFFLOAD_SCTP_CKSUM |\
> > + DEV_TX_OFFLOAD_UDP_CKSUM |\
> > + DEV_TX_OFFLOAD_TCP_CKSUM)
>
>
> Hmm and why IP_CKSUM, TSO, OUTER_IP_CKSUM, etc. is not included into
> that macro?
> In fact do you really need that?
> As I understand right now vector TX doesn't support any offloads, so
> tx_offload != 0, should be enough for tx function selection, right?
> Konstanitn
In this patch, IXGBE_SIMPLE_TX_OFFLOAD_FLAGS is just a reverse transform of
IXGBE_SIMPLE_FLAGS which is used in old offload API.
Yes, current vector Tx doesn't support any offloads.
I will use tx_offload==0 following your guide.
>
> > +
> > /*
> > * Populate descriptors with the following info:
> > * 1.) buffer_addr = phys_addr + headroom @@ -307,6 +314,7 @@
> > uint16_t ixgbe_xmit_fixed_burst_vec(void *tx_queue, struct rte_mbuf
> **tx_pkts,
> > uint16_t nb_pkts);
> > int ixgbe_txq_vec_setup(struct ixgbe_tx_queue *txq);
> >
> > +uint64_t ixgbe_get_tx_port_offlaods(struct rte_eth_dev *dev);
> > uint64_t ixgbe_get_rx_queue_offloads(struct rte_eth_dev *dev);
> > uint64_t ixgbe_get_rx_port_offloads(struct rte_eth_dev *dev);
> >
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v2 3/4] net/ixgbe: convert to new Rx offloads API
Hi, Konstantin
Thanks for your feedback.
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Thursday, March 15, 2018 5:48 AM
> To: Dai, Wei ; Lu, Wenzhuo
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v2 3/4] net/ixgbe: convert to new Rx offloads API
>
> Hi Wei,
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, March 7, 2018 1:06 PM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> >
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v2 3/4] net/ixgbe: convert to new Rx offloads API
> >
> > Ethdev Rx offloads API has changed since:
> > commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") This
> > commit support the new Rx offloads API.
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/ixgbe/ixgbe_ethdev.c | 93 +
> > drivers/net/ixgbe/ixgbe_ipsec.c | 8 +-
> > drivers/net/ixgbe/ixgbe_rxtx.c| 163
> ++
> > drivers/net/ixgbe/ixgbe_rxtx.h| 3 +
> > drivers/net/ixgbe/ixgbe_rxtx_vec_common.h | 2 +-
> > drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c | 2 +-
> > 6 files changed, 205 insertions(+), 66 deletions(-)
> >
> > +uint64_t
> > +ixgbe_get_rx_queue_offloads(struct rte_eth_dev *dev) {
> > + uint64_t offloads;
> > + struct ixgbe_hw *hw =
> > +IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > +
> > + offloads = DEV_RX_OFFLOAD_HEADER_SPLIT;
>
> As I can see I ixgbe all header_split code is enabled only if
> RTE_HEADER_SPLIT_ENABLE is on.
> It is off by default and I doubt anyone really using it these days.
> So I think the best thing would be not to advertise
> DEV_RX_OFFLOAD_HEADER_SPLIT for ixgbe at all, and probably remove
> related code.
> If you'd prefer to keep it, then at least we should set that capability only
> at
> #ifdef RTE_HEADER_SPLIT_ENABLE.
> Another thing - it should be per port, not per queue.
> Thought I think better is just to remove it completely.
I will set this header splitting capability in #ifdef RTE_HEADER_SPLIT_ENABLE
in my next patch set.
I think it is a per queue capability as it can be configured on the register
IXGBE_SRRCTL of every Rx queue
In this code line: IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(rxq->reg_idx), srrctl); in
ixgbe_dev_rx_init( ).
Same case is also in the code line: IXGBE_WRITE_REG(hw, IXGBE_VFSRRCTL(i),
srrctl); in ixgbevf_dev_rx_init( ).
> > +static int
> > +ixgbe_check_rx_queue_offloads(struct rte_eth_dev *dev, uint64_t
> > +requested) {
> > + uint64_t port_offloads = dev->data->dev_conf.rxmode.offloads;
> > + uint64_t queue_supported = ixgbe_get_rx_queue_offloads(dev);
> > + uint64_t port_supported = ixgbe_get_rx_port_offloads(dev);
> > +
> > + if ((requested & (queue_supported | port_supported)) != requested)
> > + return 0;
> > +
> > + if ((port_offloads ^ requested) & port_supported)
>
> Could you explain a bit more what are you cheking here?
> As I can see:
> (port_offloads ^ requested) - that's a diff between already set and newly
> requested offloads.
> Then you check if that diff consists of supported by port offloads, and if yes
> you return an error?
> Konstantin
>
This function is similar to mlx4_check_rx_queue_offloads() in mlx4 driver.
As the git log message in the commit ce17eddefc20285bbfe575bdc07f42f0b20f34cb
say
that a per port capability should has same setting (enabling or disabling) on
both port
configuration via rte_eth_dev_configure( ) and queue configuration via
rte_eth_rx_queue_setup( ).
This function check if this requirement is matched or not.
It also check offloading request is supported as a per port or a per queue
capability or not.
If above checking is pass, it return 1 else return 0.
Re: [dpdk-dev] [PATCH v2 1/2] app/testpmd: add commands to test new Rx offload API
> -Original Message-
> From: Wu, Jingjing
> Sent: Thursday, March 15, 2018 3:41 AM
> To: Dai, Wei ; Lu, Wenzhuo
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v2 1/2] app/testpmd: add commands to test new Rx
> offload API
>
> <...>
>
> > +static int
> > +config_rx_offload(const char *name, uint64_t *offload, int on) {
> > + uint64_t local = *offload;
> > +
> > + if (!strcmp(name, "vlan_strip")) {
> > + if (on)
> > + local |= DEV_RX_OFFLOAD_VLAN_STRIP;
> > + else
> > + local &= ~DEV_RX_OFFLOAD_VLAN_STRIP;
> Would it decrease the lines if move the "on" checking to the end of this
> function, just set the BIT which you want to set or mask here?
Thanks, will follow your suggestion in v3 patch set.
> <...>
>
> > +static void
> > +cmd_config_per_port_rx_offload_parsed(void *parsed_result,
> > + __attribute__((unused)) struct cmdline *cl,
> > + __attribute__((unused)) void *data) {
> > + struct cmd_config_per_port_rx_offload_result *res = parsed_result;
> > + portid_t port_id = res->port_id;
> > + struct rte_port *port = &ports[port_id];
> > + int on;
> > +
> > + if (port->port_status != RTE_PORT_STOPPED) {
> > + printf("Error: Can't config offload when Port %d "
> > + "is not stopped\n", port_id);
> > + return;
> > + }
> > +
> > + if (!strcmp(res->en_dis, "enable"))
> > + on = 1;
> > + else if (!strcmp(res->en_dis, "disable"))
> > + on = 0;
> > + else {
> > + printf("Unknown parameter: %s\n", res->en_dis);
> > + return;
> The en_dis is already defined as "enable#disable", so the else is useless
> here.
Thanks, the second if and second else can be removed and will change in v3
patch set.
>
> <...>
>
> > +static void
> > +cmd_config_per_queue_rx_offload_parsed(void *parsed_result,
> > + __attribute__((unused)) struct cmdline *cl,
> > + __attribute__((unused)) void *data) {
> > + struct cmd_config_per_queue_rx_offload_result *res = parsed_result;
> > + struct rte_eth_dev_info dev_info;
> > + portid_t port_id = res->port_id;
> > + uint16_t queue_id = res->queue_id;
> > + struct rte_port *port = &ports[port_id];
> > + int on;
> > +
> > + if (port->port_status != RTE_PORT_STOPPED) {
> > + printf("Error: Can't config offload when Port %d "
> > + "is not stopped\n", port_id);
> > + return;
> > + }
> > +
> > + if (!strcmp(res->en_dis, "enable"))
> > + on = 1;
> > + else if (!strcmp(res->en_dis, "disable"))
> > + on = 0;
> > + else {
> > + printf("Unknown parameter: %s\n", res->en_dis);
> > + return;
> Same comments as above.
> <...>
>
> > @@ -707,6 +708,17 @@ init_config(void)
> > }
> > }
> >
> > + port->rx_offloads = rte_zmalloc("testpmd: port->rx_offloads",
> > + sizeof(port->rx_offloads[0]) *
> > + port->dev_info.max_rx_queues,
> > + sizeof(port->rx_offloads[0]));
>
> When will you free it?
I will free port->rx_offloads and port->tx_offloads when testpmd is existed.
>
> > + if (port->rx_offloads == NULL)
> > + rte_exit(EXIT_FAILURE,
> > +"rte_zmalloc(%d port->rx_offload[0]) "
> > +"failed\n", port->dev_info.max_rx_queues);
> > + for (k = 0; k < port->dev_info.max_rx_queues; k++)
> > + port->rx_offloads[k] = port->dev_conf.rxmode.offloads;
> > +
> In the get configure command, the port->rx_offloads is printed.
> Here you init it to be port configuration, when will you update it?
This init_config() is only run once in the initialization stage in the main().
Port->rx_offloads[] can be changed using new testpmd command in this patch set.
Testpmd> rx_offload enable/disable per_queue
And will be applied when the command port start is run.
Re: [dpdk-dev] [PATCH v2 1/2] app/testpmd: add commands to test new Rx offload API
Thanks to Konstantin and Andrew for your feedback. I will use __builtin_ctzll() and __builtin_clzll() in my v3 patch set. I also will use strcasecmp and loop to do config_rx_offload() and config_tx_offload() following your guidance. > -Original Message- > From: Ananyev, Konstantin > Sent: Tuesday, March 13, 2018 5:31 PM > To: Andrew Rybchenko ; Dai, Wei > ; Lu, Wenzhuo ; Wu, Jingjing > > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 1/2] app/testpmd: add commands to test > new Rx offload API > > > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Andrew > Rybchenko > > Sent: Tuesday, March 13, 2018 7:21 AM > > To: Dai, Wei ; Lu, Wenzhuo > ; > > Wu, Jingjing > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2 1/2] app/testpmd: add commands to > > test new Rx offload API > > > > On 03/13/2018 09:42 AM, Wei Dai wrote: > > > Add following testpmd run-time commands to support test of new Rx > > > offload API: > > > rx_offload get capability > > > rx_offload get configuration rx_offload enable|disable > > > per_port rx_offload enable|disable per_queue > > > > > > > > > Above last 2 commands should be run when the port is stopped. > > > And can be one of "vlan_strip", "ipv4_cksum", ... > > > > > > Signed-off-by: Wei Dai > > > --- > > > + for (single_offload = DEV_RX_OFFLOAD_VLAN_STRIP; > > > + single_offload <= DEV_RX_OFFLOAD_SECURITY; > > > > It requires attention when a new offload is added. > > Please, consider to use something like __builtin_ffsll(), print name > > of the found bit, clear it and retry. It allows to avoid boundaries > > specification. > > > > > > > > > > I was going to suggest rte_eth_dev_rx_offload_name(), strcasecmp() and > loop. > > +1 > > > It is possible to iterate on all U64 bits or add a way to get all > > offload bits from rte_ethdev. > > However it still requires list of offloads in the help below. So, it > > is not easy to get rig of offloads list completely. Just an idea. Up > > to you. > > > > > >
Re: [dpdk-dev] [PATCH 1/2] app/testpmd: add commands to test new Rx offload API
> -Original Message-
> From: Andrew Rybchenko [mailto:arybche...@solarflare.com]
> Sent: Monday, March 12, 2018 4:43 PM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Wu, Jingjing
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] app/testpmd: add commands to test
> new Rx offload API
>
> On 03/12/2018 11:15 AM, Wei Dai wrote:
> > Add following testpmd run-time commands to support test of new Rx
> > offload API:
> > rx_offload get capability
> > rx_offload get configuration rx_offload enable|disable
> > per_port vlan_strip|ipv4_cksum... rx_offload enable|disable
> > per_queue vlan_strip|iipv4_cksum...
> >
> > Above last 2 commands should be run when the port is stopped.
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 456
> +
> > app/test-pmd/testpmd.c | 15 +-
> > app/test-pmd/testpmd.h | 1 +
> > 3 files changed, 470 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > d1dc1de..1a08b3d 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -15996,6 +15996,458 @@ cmdline_parse_inst_t
> cmd_ptype_mapping_update = {
> > },
> > };
> >
> > +static const char * const rx_offload_names[] = {
> > + "VLAN_STRIP",
> > + "IPV4_CKSUM",
> > + "UDP_CKSUM",
> > + "TCP_CKSUM",
> > + "TCP_LRO",
> > + "QINQ_STRIP",
> > + "OUTER_IPV4_CKSUM",
> > + "MACSEC_STRIP",
> > + "HEADER_SPLIT",
> > + "VLAN_FILTER",
> > + "VLAN_EXTEND",
> > + "JUMBO_FRAME",
> > + "CRC_STRIP",
> > + "SCATTER",
> > + "TIMESTAMP",
> > + "SECURITY"
> > +};
>
> There are already rte_rx_offload_names in librte_ethdev/rte_ethdev.c and
> rte_eth_dev_rx_offload_name() function in API.
Andrew, thanks for your feedback.
I will use rte_eth_dev_rx_offload_name( ) in my v2 patch set.
Re: [dpdk-dev] net/ixgbe: fix VFIO interrupt mapping in PF
I add this code line to align same style and same action taken in ixgbe VF and i40e VF. In ixgbe VF or i40e VF, without this line, the initialization of Rx queue interrupt mapping to VFIO-PCI vectors would fail. I have tested it in ixgbe PF port with example/l3fwd-power and found the interrupt can be initialized successfully and Rx queue can be waked up by incoming packets no matter whether this line exists or not. So I decide to reject it now. > -Original Message- > From: Yang, Qiming > Sent: Wednesday, January 10, 2018 2:29 PM > To: Lu, Wenzhuo ; Dai, Wei > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] net/ixgbe: fix VFIO interrupt mapping in PF > > +1 why we disable interrupt in dev_start twice? > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu > > Sent: Tuesday, January 9, 2018 4:24 PM > > To: Dai, Wei > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] net/ixgbe: fix VFIO interrupt mapping in PF > > > > Hi Wei, > > > > > + rte_intr_disable(intr_handle); > > TBH, confused by this patch. I see the intr already disabled at the > > begining of this function, ixgbe_dev_start, why we need to disable it > again?
Re: [dpdk-dev] [PATCH v3 1/6] net/ixgbevf: unregister irq handler when other interrupts not allowed.
> -Original Message-
> From: xiangxia.m@gmail.com [mailto:xiangxia.m@gmail.com]
> Sent: Sunday, January 14, 2018 6:04 PM
> To: Dai, Wei ; Xing, Beilei
> Cc: dev@dpdk.org; Tonghao Zhang
> Subject: [PATCH v3 1/6] net/ixgbevf: unregister irq handler when other
> interrupts not allowed.
>
> From: Tonghao Zhang
>
> When bind the ixgbe VF (e.g 82599 card) to igb_uio and enable the
> rx-interrupt, there will be more than one epoll_wait on intr_handle.fd.
> One is in "eal-intr-thread" thread, and the others are in the thread which
> call
> the "rte_epoll_wait". The problem is that sometimes "eal-intr-thread" thread
> will process the rx interrupt, and then rte_epoll_wait can't get the event
> anymore, and the packets may be lost.
>
> The patch unregister the status interrupt handler in "eal-intr-thread"
> thread and the ixgbe pf is in the same case.
>
> Signed-off-by: Tonghao Zhang
> Acked-by: Beilei Xing
In my feedback to your v2 version of this patch, I mentioned miscellaneous
interrupt
need to be handled in eal-intr-thread.
Your patch removes the handler of PF->VF reset event and leads to missing of
this event.
My suggestion is still using VFIO-PCI instead of igb_uio for rx-queue interrupt.
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ff19a56..0e056a2 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -5078,6 +5078,15 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> }
> ixgbevf_configure_msix(dev);
>
> + if (!rte_intr_allow_others(intr_handle)) {
> + rte_intr_callback_unregister(intr_handle,
> + ixgbevf_dev_interrupt_handler,
> + dev);
> + if (dev->data->dev_conf.intr_conf.lsc != 0)
> + PMD_INIT_LOG(INFO, "lsc won't enable because of"
> + " no intr multiplex");
> + }
> +
> /* When a VF port is bound to VFIO-PCI, only miscellaneous interrupt
>* is mapped to VFIO vector 0 in eth_ixgbevf_dev_init( ).
>* If previous VFIO interrupt mapping setting in eth_ixgbevf_dev_init( )
> @@ -5120,6 +5129,12 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
>
> ixgbe_dev_clear_queues(dev);
>
> + if (!rte_intr_allow_others(intr_handle))
> + /* resume to the default handler */
> + rte_intr_callback_register(intr_handle,
> +ixgbevf_dev_interrupt_handler,
> +(void *)dev);
> +
> /* Clean datapath event and queue/vec mapping */
> rte_intr_efd_disable(intr_handle);
> if (intr_handle->intr_vec != NULL) {
> --
> 1.8.3.1
Re: [dpdk-dev] [PATCH 4/5] net/ixgbevf: add check for rte_intr_enable.
Hi, Tonghao Thanks for your patch. It looks that same change can be applied to ixgbe_dev_interrupt_action( ) and ixgbe_dev_interrupt_delayed_handler( ). Anyway, you can test all these changes with example/l3fwd-power. -Wei > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Xing, Beilei > Sent: Thursday, January 11, 2018 3:06 PM > To: Tonghao Zhang ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 4/5] net/ixgbevf: add check for > rte_intr_enable. > > > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Tonghao Zhang > > Sent: Friday, January 5, 2018 10:11 PM > > To: dev@dpdk.org > > Cc: Tonghao Zhang > > Subject: [dpdk-dev] [PATCH 4/5] net/ixgbevf: add check for > rte_intr_enable. > > The patch is not only for ixgbevf, but also for ixgbe, right? > so how about changing the title with net/ixgbe started? > > > When we bind the ixgbevf to vfio and call the > > rte_eth_dev_rx_intr_enable and rte_eth_dev_rx_intr_disable frequently, > > the interrupt setting > > (msi_set_mask_bit) will take more CPU as show below. rte_intr_enable > > call the ioctl to map the fd to interrupts frequently. > > > > perf top: > > 5.45% [kernel] [k] msi_set_mask_bit > > > > It is unnecessary to call the rte_intr_enable in > > ixgbe_dev_rx_queue_intr_enable. because the fds has been mapped to > > interrupt and not unmapped in ixgbe_dev_rx_queue_intr_disable. > > > > This patch add checks for using VFIO. With the patch, > > msi_set_mask_bit is not listed in perl any more. Any suggestion will be > welcome. > > > > Signed-off-by: Tonghao Zhang > > --- > > drivers/net/ixgbe/ixgbe_ethdev.c | 9 +++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c > > b/drivers/net/ixgbe/ixgbe_ethdev.c > > index e929235..79e4097 100644 > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > > @@ -5610,7 +5610,9 @@ static void ixgbevf_set_vfta_all(struct > > rte_eth_dev *dev, bool on) > > RTE_SET_USED(queue_id); > > IXGBE_WRITE_REG(hw, IXGBE_VTEIMS, intr->mask); > > > > - rte_intr_enable(intr_handle); > > + if (intr_handle->type == RTE_INTR_HANDLE_UIO || > > + intr_handle->type == RTE_INTR_HANDLE_UIO_INTX) > > + rte_intr_enable(intr_handle); > > For igb_uio, did you check if it's necessary to call rte_intr_enable every > time? > Since rte interrupt is not disabled during ixgbevf_dev_rx_queue_intr_disable. > > > > > return 0; > > } > > @@ -5659,7 +5661,10 @@ static void ixgbevf_set_vfta_all(struct > > rte_eth_dev *dev, bool on) > > mask &= (1 << (queue_id - 32)); > > IXGBE_WRITE_REG(hw, IXGBE_EIMS_EX(1), mask); > > } > > - rte_intr_enable(intr_handle); > > + > > + if (intr_handle->type == RTE_INTR_HANDLE_UIO || > > + intr_handle->type == RTE_INTR_HANDLE_UIO_INTX) > > + rte_intr_enable(intr_handle); > > The same comment as above. > > > > > return 0; > > } > > -- > > 1.8.3.1
Re: [dpdk-dev] [PATCH v2 3/4] net/ixgbevf: save IXGBE_VTEIMS to intr->mask for performance.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of
> xiangxia.m@gmail.com
> Sent: Friday, January 12, 2018 12:40 AM
> To: Xing, Beilei ; dev@dpdk.org
> Cc: Tonghao Zhang
> Subject: [dpdk-dev] [PATCH v2 3/4] net/ixgbevf: save IXGBE_VTEIMS to
> intr->mask for performance.
>
> From: Tonghao Zhang
>
> If dpdk APPs call the rte_eth_dev_rx_intr_enable or
> rte_eth_dev_rx_intr_disable frequently, and ixgbe vf will read the
> IXGBE_VTEIMS register everytime. The patch saves the IXGBE_VTEIMS to
> mask to avoid read frequently.
>
> Signed-off-by: Tonghao Zhang
> Acked-by: Beilei Xing
Acked-by: Wei Dai
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 55
> +---
> 1 file changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 49f486a..cab243d 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -270,8 +270,8 @@ static int ixgbevf_dev_link_update(struct
> rte_eth_dev *dev, static void ixgbevf_dev_stop(struct rte_eth_dev *dev);
> static void ixgbevf_dev_close(struct rte_eth_dev *dev); static int
> ixgbevf_dev_reset(struct rte_eth_dev *dev); -static void
> ixgbevf_intr_disable(struct ixgbe_hw *hw); -static void
> ixgbevf_intr_enable(struct ixgbe_hw *hw);
> +static void ixgbevf_intr_disable(struct rte_eth_dev *dev); static void
> +ixgbevf_intr_enable(struct rte_eth_dev *dev);
> static int ixgbevf_dev_stats_get(struct rte_eth_dev *dev,
> struct rte_eth_stats *stats);
> static void ixgbevf_dev_stats_reset(struct rte_eth_dev *dev); @@ -1665,7
> +1665,7 @@ static int ixgbe_l2_tn_filter_init(struct rte_eth_dev *eth_dev)
> ixgbevf_dev_stats_reset(eth_dev);
>
> /* Disable the interrupts for VF */
> - ixgbevf_intr_disable(hw);
> + ixgbevf_intr_disable(eth_dev);
>
> hw->mac.num_rar_entries = 128; /* The MAX of the underlying PF */
> diag = hw->mac.ops.reset_hw(hw);
> @@ -1734,7 +1734,7 @@ static int ixgbe_l2_tn_filter_init(struct
> rte_eth_dev *eth_dev)
> rte_intr_callback_register(intr_handle,
> ixgbevf_dev_interrupt_handler, eth_dev);
> rte_intr_enable(intr_handle);
> - ixgbevf_intr_enable(hw);
> + ixgbevf_intr_enable(eth_dev);
>
> PMD_INIT_LOG(DEBUG, "port %d vendorID=0x%x deviceID=0x%x
> mac.type=%s",
>eth_dev->data->port_id, pci_dev->id.vendor_id, @@
> -1767,7 +1767,7 @@ static int ixgbe_l2_tn_filter_init(struct rte_eth_dev
> *eth_dev)
> eth_dev->tx_pkt_burst = NULL;
>
> /* Disable the interrupts for VF */
> - ixgbevf_intr_disable(hw);
> + ixgbevf_intr_disable(eth_dev);
>
> rte_free(eth_dev->data->mac_addrs);
> eth_dev->data->mac_addrs = NULL;
> @@ -4953,19 +4953,32 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> * Virtual Function operations
> */
> static void
> -ixgbevf_intr_disable(struct ixgbe_hw *hw)
> +ixgbevf_intr_disable(struct rte_eth_dev *dev)
> {
> + struct ixgbe_interrupt *intr =
> + IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
> + struct ixgbe_hw *hw =
> + IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> PMD_INIT_FUNC_TRACE();
>
> /* Clear interrupt mask to stop from interrupts being generated */
> IXGBE_WRITE_REG(hw, IXGBE_VTEIMC, IXGBE_VF_IRQ_CLEAR_MASK);
>
> IXGBE_WRITE_FLUSH(hw);
> +
> + /* Clear mask value. */
> + intr->mask = 0;
> }
>
> static void
> -ixgbevf_intr_enable(struct ixgbe_hw *hw)
> +ixgbevf_intr_enable(struct rte_eth_dev *dev)
> {
> + struct ixgbe_interrupt *intr =
> + IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
> + struct ixgbe_hw *hw =
> + IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> PMD_INIT_FUNC_TRACE();
>
> /* VF enable interrupt autoclean */
> @@ -4974,6 +4987,9 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> IXGBE_WRITE_REG(hw, IXGBE_VTEIMS,
> IXGBE_VF_IRQ_ENABLE_MASK);
>
> IXGBE_WRITE_FLUSH(hw);
> +
> + /* Save IXGBE_VTEIMS value to mask. */
> + intr->mask = IXGBE_VF_IRQ_ENABLE_MASK;
> }
>
> static int
> @@ -5099,7 +5115,7 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> rte_intr_enable(intr_handle);
>
> /* Re-enable interrupt for VF */
> - ixgbevf_intr_enable(hw);
> + ixgbevf_intr_enable(dev);
>
> return 0;
> }
> @@ -5113,7 +5129,7 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
>
> PMD_INIT_FUNC_TRACE();
>
> - ixgbevf_intr_disable(hw);
> + ixgbevf_intr_disable(dev);
>
> hw->adapter_stopped = 1;
> ixgbe_stop_adapter(hw);
> @@ -5611,17 +5627,17 @@ static void ixgbevf_set_vfta_all(struct
> rte_eth_dev *dev, bool on) {
> struct rte_pci_device *pci_dev =
Re: [dpdk-dev] [PATCH v2 1/4] net/ixgbevf: unregister irq handler when other interrupts not allowed.
Hi, Tonghao & Beilei
The issue reported by Tonghao is caused by shortage of igb_uio.
If you want to use Rx queue interrupt in your DPDK application,
I suggest use VFIO-PCI to bind NIC port instead of igb_uio.
Currently igb_uio only support single event fd. This fd is triggered by
both miscellaneous and RX queue interrupt in ixgbe VF.
But same event fd is added to epoll fd of eal-intr-thread
and also epoll fd of normal thread for Rx task, this cause the issue.
If VFIO-PCI is used, different event fd for misc and Rx queue are created.
By the way, your patch also lead to missing of PF to VF reset interrupt.
So, I am sorry that I can't agree it now.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of
> xiangxia.m@gmail.com
> Sent: Friday, January 12, 2018 12:40 AM
> To: Xing, Beilei ; dev@dpdk.org
> Cc: Tonghao Zhang
> Subject: [dpdk-dev] [PATCH v2 1/4] net/ixgbevf: unregister irq handler when
> other interrupts not allowed.
>
> From: Tonghao Zhang
>
> When bind the ixgbe VF (e.g 82599 card) to igb_uio and enable the
> rx-interrupt, there will be more than one epoll_wait on intr_handle.fd.
> One is in "eal-intr-thread" thread, and the others are in the thread which
> call
> the "rte_epoll_wait". The problem is that sometimes "eal-intr-thread" thread
> will process the rx interrupt, and then rte_epoll_wait can't get the event
> anymore, and the packets may be lost.
>
> The patch unregister the status interrupt handler in "eal-intr-thread"
> thread and the ixgbe pf is in the same case.
>
> Signed-off-by: Tonghao Zhang
> Acked-by: Beilei Xing
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ff19a56..0e056a2 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -5078,6 +5078,15 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> }
> ixgbevf_configure_msix(dev);
>
> + if (!rte_intr_allow_others(intr_handle)) {
> + rte_intr_callback_unregister(intr_handle,
> + ixgbevf_dev_interrupt_handler,
> + dev);
> + if (dev->data->dev_conf.intr_conf.lsc != 0)
> + PMD_INIT_LOG(INFO, "lsc won't enable because of"
> + " no intr multiplex");
> + }
> +
> /* When a VF port is bound to VFIO-PCI, only miscellaneous interrupt
>* is mapped to VFIO vector 0 in eth_ixgbevf_dev_init( ).
>* If previous VFIO interrupt mapping setting in eth_ixgbevf_dev_init( )
> @@ -5120,6 +5129,12 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
>
> ixgbe_dev_clear_queues(dev);
>
> + if (!rte_intr_allow_others(intr_handle))
> + /* resume to the default handler */
> + rte_intr_callback_register(intr_handle,
> +ixgbevf_dev_interrupt_handler,
> +(void *)dev);
> +
> /* Clean datapath event and queue/vec mapping */
> rte_intr_efd_disable(intr_handle);
> if (intr_handle->intr_vec != NULL) {
> --
> 1.8.3.1
Re: [dpdk-dev] [PATCH v4 0/2] app/testpmd: fix invalid rxq and txq nubmer settings
Hi, Yuan
I can build dpdk with my patches successfully in my Fedora 24 with gcc 6.3.1
20161221 (Red Hat 6.3.1-1)
Anyway, I will make v5 patch to address the problem you report and correct
typos reported by Konstantin.
Thanks
> -Original Message-
> From: Peng, Yuan
> Sent: Friday, January 12, 2018 1:40 PM
> To: Dai, Wei ; Ananyev, Konstantin
> ; Yang, Qiming ;
> Lu, Wenzhuo ; Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v4 0/2] app/testpmd: fix invalid rxq and txq nubmer
> settings
>
> Hi Wei,
>
> There is a build error applied your patches to the latest DPDK version.
> /root/dpdk/app/test-pmd/testpmd.c: In function 'check_nb_rxq':
> /root/dpdk/app/test-pmd/testpmd.c:579:3: error: 'pid' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>printf("Fail: input rxq (%u) can't be greater "
>^
> /root/dpdk/app/test-pmd/testpmd.c: In function 'check_nb_txq':
> /root/dpdk/app/test-pmd/testpmd.c:625:3: error: 'pid' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>printf("Fail: input txq (%u) can't be greater "
>^
> My gcc verison is gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
>
> Could you help to check it?
>
> Thanks.
> Yuan.
>
> -Original Message-
> From: Dai, Wei
> Sent: Thursday, January 11, 2018 12:58 PM
> To: Ananyev, Konstantin ; Yang, Qiming
> ; Peng, Yuan ; Lu,
> Wenzhuo ; Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> Subject: [PATCH v4 0/2] app/testpmd: fix invalid rxq and txq nubmer settings
>
> If an invlaid number of RX or TX queues is configured from testpmd
> command like "port config all rxq number" or "port config all txq number".
> or from --rxq and --txq in the command to start testpmd. The global variable
> nb_rxq or nb_txq is updated by the invalid input.
> This can cause testpmd crash. For example, if the maximum number of RX or
> TX queues is 4, testpmd will crash after running commands "port config all
> rxq 5", "port config all txq 5" and "start" in sequence.
>
> With these 2 patches, if an invalid input is detected, it is refused and
> testpmd
> keeps last correct values of nb_rxq and nb_txq.
>
> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> Aced-by: Konstantin Ananyev
>
> ---
> v4: update git log message and rename 2 new added functions
>
> v3: follow the guide from Konstantin to use functions to check
> input rxq and txq instead of usage of new added global variables.
>
> v2: fix a bug in v1
>
>
>
> Wei Dai (2):
> app/testpmd: fix invalid rxq number setting
> app/testpmd: fix invalid txq number setting
>
> app/test-pmd/cmdline.c| 4 +++
> app/test-pmd/parameters.c | 13 +++
> app/test-pmd/testpmd.c| 92
> +++
> app/test-pmd/testpmd.h| 5 +++
> 4 files changed, 108 insertions(+), 6 deletions(-)
>
> --
> 2.7.5
Re: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF
> -Original Message- > From: Wu, Yanglong > Sent: Friday, January 12, 2018 10:38 AM > To: Dai, Wei ; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > Hi > After confirm with Daiwei and according to the data sheet, > RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool is the Max number of queue can > be used in VF, that would be assigned as IXGBE_MAX_RX_QUEUE_NUM / > RTE_ETH_DEV_SRIOV(dev).active, so that assigning nb_q_per_pool as 1 > when PF is in ETH_MQ_RX_NONE, which will make VF can just use only 1 > queue, is not right. So this patch is right. > > Yanglong > > -Original Message- > From: Wu, Yanglong > Sent: Thursday, January 11, 2018 11:29 PM > To: Wu, Yanglong ; Dai, Wei > ; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > Hi daiwei: > > After I double checked with this bug, the problem can be described as follow: > When we start PF using testpmd like this: testpmd -c 0x3 -n 4 > --socket-mem=1024,1024 --file-prefix=pf -w :05:00.0 -w :05:00.1 > -- -i. The number of queue signed to each port would be 1 and the > rxmode.mq_mode of ixgbe eth_dev would be set as ETH_MQ_RX_NONE. > And this config info is make sense, so until now there is no problem, right? > And according to the code: > case ETH_MQ_RX_NONE: > > /* if nothing mq mode configure, use default scheme */ > > dev->data->dev_conf.rxmode.mq_mode = > ETH_MQ_RX_VMDQ_ONLY; > > - if (RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool > 1) > > - RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = 1; > > break; > The nb_q_per_pool of (RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool would > be set as 1, that means for VF the number of max queue can be used would > be only 1. > > And next we start VF using l3fwd: > l3fwd/build/l3fwd -c 0xc -n 4 -w :05:10.0 -w :05:10.1 -- -p 0x3 > --config '(0,0,18),(1,0,19)' --parse-ptype The number of rx_q equal to 1 and > there is no problem. But, in l3fwd, the number of tx_q would equal to the > number of core used in l3fwd, so here number of tx_q equal to 2 but as > described above, the max number of queue can be used in VF is just only 1. > So there is problem and l3fwd will check failed. > > > So there is two ways to fix this bug, the first is using this patch, don't > assign > RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool as 1 when mq_mode = > ETH_MQ_RX_VMDQ_ONLY. > And the second is that the number of tx_q would not assigned as the number > of cores used in l3fwd. > > Which one do you think is make sense? > > > > > Yanglong > > > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wu, Yanglong > Sent: Thursday, January 11, 2018 6:30 PM > To: Dai, Wei ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > Yes, this problem is caused by PF passing a wrong number of queue to VF. So > basically, I removed model check of "case ETH_MQ_RX_NONE". It seem > right after I do that but I'am also not very sure the changing is really > right. So > thank to your comments, I will redebug this problem. > > -Original Message- > From: Dai, Wei > Sent: Thursday, January 11, 2018 5:48 PM > To: Wu, Yanglong ; dev@dpdk.org; Yang, Zhiyong > > Cc: Wu, Yanglong > Subject: RE: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > According to 82599 datasheet, VF working mode is controlled by its host PF. > If VF is working in RSS or DCB mode, it can use more than 1 queues. > That also means its host PF should enable RSS or DCB. > The PF Rx mode can be ETH_MQ_RX_VMDQ_RSS or > ETH_MQ_RX_VMDQ_DCB. > So I think that DPDK app with PF cause this issue, not ixgbe PMD itself. > > By the way, you can reply your patch mail to provide more info about how > You reproduce this issue to easy others' reviewing and testing your patch. > > Thanks > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu > > Sent: Tuesday, January 9, 2018 2:32 PM > > To: dev@dpdk.org; Yang, Zhiyong > > Cc: Wu, Yanglong > > Subject: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > > > VF can't run in multi queue mode, if nb_q_per_pool was set as 1. > > Nb_q_per_pool is passed through to max_rx_q and max_tx_q in VF. > > So if nb_q_per_pool is equal to 1, max_rx_q and max_tx_q can't be more > > than 1 and VF multi queue mode will fail. > > > > Fixes: 27b609cbd1c6 (ethdev: m
Re: [dpdk-dev] [PATCH 2/2] net/e1000: fix mailbox interrupt handler
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, December 28, 2017 4:23 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Dai, Wei ; Wang, Liang-min
> ; Zhang, Qi Z ;
> sta...@dpdk.org
> Subject: [PATCH 2/2] net/e1000: fix mailbox interrupt handler
>
> Mailbox interrupt handler only take care of the PF reset notification, for
> other message mbx->ops.read should not be called since it get chance to
> break the foreground VF to PF communication.
>
> Fixes: 316f4f1adc2e ("net/igb: support VF mailbox interrupt for link
> up/down")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
Acked-by: Wei Dai
> ---
> drivers/net/e1000/igb_ethdev.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/e1000/igb_ethdev.c
> b/drivers/net/e1000/igb_ethdev.c index fdc139f..0d8bc49 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -2970,13 +2970,17 @@ void igbvf_mbx_process(struct rte_eth_dev
> *dev)
> struct e1000_mbx_info *mbx = &hw->mbx;
> u32 in_msg = 0;
>
> - if (mbx->ops.read(hw, &in_msg, 1, 0))
> - return;
> + /* peek the message first */
> + in_msg = E1000_READ_REG(hw, E1000_VMBMEM(0));
>
> /* PF reset VF event */
> - if (in_msg == E1000_PF_CONTROL_MSG)
> + if (in_msg == E1000_PF_CONTROL_MSG) {
> + /* dummy mbx read to ack pf */
> + if (mbx->ops.read(hw, &in_msg, 1, 0))
> + return;
> _rte_eth_dev_callback_process(dev,
> RTE_ETH_EVENT_INTR_RESET,
> NULL, NULL);
> + }
> }
>
> static int
> --
> 2.7.4
Re: [dpdk-dev] [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, December 28, 2017 4:22 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Dai, Wei ; Wang, Liang-min
> ; Zhang, Qi Z ;
> sta...@dpdk.org
> Subject: [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
>
> Mailbox interrupt handler only take care of PF reset notification, for other
> message ixgbe_read_mbx should not be called since it get chance to break
> the foreground VF to PF communication.
> This can be simply repeated by
> testpmd>rx_vlan rm all 0
>
> Fixes: 77234603fba0 ("net/ixgbe: support VF mailbox interrupt for link
> up/down")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
Acked-by: Wei Dai
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ff19a56..02121f4 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -8165,13 +8165,17 @@ static void ixgbevf_mbx_process(struct
> rte_eth_dev *dev)
> struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> u32 in_msg = 0;
>
> - if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> - return;
> + /* peek the message first */
> + in_msg = IXGBE_READ_REG(hw, IXGBE_VFMBMEM);
>
> /* PF reset VF event */
> - if (in_msg == IXGBE_PF_CONTROL_MSG)
> + if (in_msg == IXGBE_PF_CONTROL_MSG) {
> + /* dummy mbx read to ack pf */
> + if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> + return;
> _rte_eth_dev_callback_process(dev,
> RTE_ETH_EVENT_INTR_RESET,
> NULL, NULL);
> + }
> }
>
> static int
> --
> 2.7.4
Re: [dpdk-dev] [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, January 11, 2018 4:08 PM
> To: Dai, Wei ; Lu, Wenzhuo
> Cc: dev@dpdk.org; Wang, Liang-min ;
> sta...@dpdk.org
> Subject: RE: [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Thursday, December 28, 2017 12:39 PM
> > To: Zhang, Qi Z ; Lu, Wenzhuo
> >
> > Cc: dev@dpdk.org; Wang, Liang-min ;
> > sta...@dpdk.org
> > Subject: RE: [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
> >
> > According to step 7 & 8 in Table 7-74 PF-to-VF Messaging Flow in 82599
> > datasheet, The calling of ixgbe_read_mbx( ) can be replaced by
> > following lines to avoid touching ->mbx.v2p_mailbox,
> > IXGBE_WRITE_REG(hw, IXGBE_VFMAILBOX, IXGBE_VFMAILBOX_ACK);
>
> Thanks for the suggestion.
>
> I think the patch try to keep things unchanged when a PF reset happen, but it
> is not going to cover the case that PF reset interrupt and a foreground VF to
> PF request happen simultaneously which is an knowing issue Your suggestion
> may help on that, but it is not a complete fix. I think it will be better to
> have
> a separate patch that focus on it.
Agree with you.
>
> Regards
> Qi
> >
> > > -Original Message-
> > > From: Zhang, Qi Z
> > > Sent: Thursday, December 28, 2017 4:22 AM
> > > To: Lu, Wenzhuo
> > > Cc: dev@dpdk.org; Dai, Wei ; Wang, Liang-min
> > > ; Zhang, Qi Z ;
> > > sta...@dpdk.org
> > > Subject: [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
> > >
> > > Mailbox interrupt handler only take care of PF reset notification,
> > > for other message ixgbe_read_mbx should not be called since it get
> > > chance to break the foreground VF to PF communication.
> > > This can be simply repeated by
> > > testpmd>rx_vlan rm all 0
> > >
> > > Fixes: 77234603fba0 ("net/ixgbe: support VF mailbox interrupt for
> > > link
> > > up/down")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Qi Zhang
Acked-by: Wei Dai
> > > ---
> > > drivers/net/ixgbe/ixgbe_ethdev.c | 10 +++---
> > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > index ff19a56..02121f4 100644
> > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > @@ -8165,13 +8165,17 @@ static void ixgbevf_mbx_process(struct
> > > rte_eth_dev *dev)
> > > struct ixgbe_hw *hw =
> > > IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > > u32 in_msg = 0;
> > >
> > > - if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> > > - return;
> > > + /* peek the message first */
> > > + in_msg = IXGBE_READ_REG(hw, IXGBE_VFMBMEM);
> > >
> > > /* PF reset VF event */
> > > - if (in_msg == IXGBE_PF_CONTROL_MSG)
> > > + if (in_msg == IXGBE_PF_CONTROL_MSG) {
> > > + /* dummy mbx read to ack pf */
> > > + if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> > > + return;
> > > _rte_eth_dev_callback_process(dev,
> > > RTE_ETH_EVENT_INTR_RESET,
> > > NULL, NULL);
> > > + }
> > > }
> > >
> > > static int
> > > --
> > > 2.7.4
Re: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF
According to 82599 datasheet, VF working mode is controlled by its host PF. If VF is working in RSS or DCB mode, it can use more than 1 queues. That also means its host PF should enable RSS or DCB. The PF Rx mode can be ETH_MQ_RX_VMDQ_RSS or ETH_MQ_RX_VMDQ_DCB. So I think that DPDK app with PF cause this issue, not ixgbe PMD itself. By the way, you can reply your patch mail to provide more info about how You reproduce this issue to easy others' reviewing and testing your patch. Thanks > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu > Sent: Tuesday, January 9, 2018 2:32 PM > To: dev@dpdk.org; Yang, Zhiyong > Cc: Wu, Yanglong > Subject: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > VF can't run in multi queue mode, if nb_q_per_pool was set as 1. > Nb_q_per_pool is passed through to max_rx_q and max_tx_q in VF. > So if nb_q_per_pool is equal to 1, max_rx_q and max_tx_q can't be more > than 1 and VF multi queue mode will fail. > > Fixes: 27b609cbd1c6 (ethdev: move the multi-queue mode check) > > Signed-off-by: Yanglong Wu > --- > v1~v3: > coding style issue fix > --- > v4: > Rework according to comments > --- > drivers/net/ixgbe/ixgbe_ethdev.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c > b/drivers/net/ixgbe/ixgbe_ethdev.c > index baaeee5d9..6af4f8b2b 100644 > --- a/drivers/net/ixgbe/ixgbe_ethdev.c > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > @@ -2240,8 +2240,6 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev) > case ETH_MQ_RX_NONE: > /* if nothing mq mode configure, use default scheme */ > dev->data->dev_conf.rxmode.mq_mode = > ETH_MQ_RX_VMDQ_ONLY; > - if (RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool > 1) > - RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = 1; > break; > default: /* ETH_MQ_RX_DCB, ETH_MQ_RX_DCB_RSS or > ETH_MQ_TX_DCB*/ > /* SRIOV only works in VMDq enable mode */ > -- > 2.11.0
Re: [dpdk-dev] [PATCH v3 0/2] app/testpmd: fix invalid rxq and txq nubmer setting
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Wednesday, January 10, 2018 5:59 PM
> To: Dai, Wei ; Yang, Qiming ;
> Peng, Yuan ; Lu, Wenzhuo ;
> Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v3 0/2] app/testpmd: fix invalid rxq and txq nubmer
> setting
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, January 10, 2018 8:41 AM
> > To: Ananyev, Konstantin ; Yang, Qiming
> > ; Peng, Yuan ; Lu,
> Wenzhuo
> > ; Wu, Jingjing
> > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > Subject: [PATCH v3 0/2] app/testpmd: fix invalid rxq and txq nubmer
> > setting
> >
> > If an invlaid number of RX or TX queues is configured from testpmd
> > command like "port config all rxq number" or "port config all txq number".
> > The global variable rxq or txq is updated by the invalid input.
> > This can cause testpmd crash. For example, if the maximum number of RX
> > or TX queues is 4, testpmd will crash after running commands "port
> > config all rxq 5", "port config all txq 5" and "start" in sequence.
> >
> > These 2 patches reserve the last correct rxq and txq, if an invalid
> > input is detected, it is restored to the backup value to avoid crash.
> >
> > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> >
> > ---
>
> The code looks good to me, just seems some misspellings in the comments
> (mimumal).
> Acked-by: Konstantin Ananyev
Thanks, Konstantin.
I'll correct these misspellings in my v4 patch set.
>
> > v3: follow the guide from Konstantin to use functions to check
> > input rxq and txq instead of usage of new added global variables.
> >
> > v2: fix a bug in v1
> >
> >
> > Wei Dai (2):
> > app/testpmd: fix invalid rxq number setting
> > app/testpmd: fix invalid txq number setting
> >
> > app/test-pmd/cmdline.c| 4 ++
> > app/test-pmd/parameters.c | 13 ---
> > app/test-pmd/testpmd.c| 94
> +++
> > app/test-pmd/testpmd.h| 5 +++
> > 4 files changed, 110 insertions(+), 6 deletions(-)
> >
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v2 2/2] app/testpmd: fix invalid txq number setting
> -Original Message-
> From: Yang, Qiming
> Sent: Wednesday, January 10, 2018 2:38 PM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Wu, Jingjing ; Peng, Yuan ;
> Ananyev, Konstantin
> Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> Subject: RE: [dpdk-dev] [PATCH v2 2/2] app/testpmd: fix invalid txq number
> setting
>
> I think the name bak is a little bit confused, what do you think just use
> nd_txq_backup/nd_rxq_backup?
> And I think it's no need to break the patch into two patch, them fix the same
> thing and the code amount are not large.
I will follow Konstantin's guide to give v3 patch set.
By the way, I think 2 patches are much clearer and keep each very simple
for others to review and for maintainer's convenience.
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Wednesday, January 10, 2018 12:14 PM
> > To: Lu, Wenzhuo ; Wu, Jingjing
> > ; Peng, Yuan ; Ananyev,
> > Konstantin
> > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > Subject: [dpdk-dev] [PATCH v2 2/2] app/testpmd: fix invalid txq number
> > setting
> >
> > If an invalid TX queue is configured from testpmd command like "port
> > config all txq number", the global variable txq is updated by this
> > invalid value. It may cause testpmd crash.
> > This patch restores its last correct value when an invalid txq number
> > configured is detected.
> >
> > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 2 ++
> > app/test-pmd/testpmd.c | 12 +--- app/test-pmd/testpmd.h |
> 1
> > +
> > 3 files changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > a5a1d57..26dd81a 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -1527,6 +1527,8 @@ cmd_config_rx_tx_parsed(void *parsed_result,
> > printf("Warning: Either rx or tx queues should be non
> > zero\n");
> > return;
> > }
> > + /* bakcup last correct nb_txq */
> > + nb_txq_bak = nb_txq;
> > nb_txq = res->value;
> > }
> > else if (!strcmp(res->name, "rxd")) { diff --git
> > a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > efafc24..8b49d96 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -190,6 +190,7 @@ queueid_t nb_rxq = 1; /**< Number of RX queues
> per
> > port. */ queueid_t nb_txq = 1; /**< Number of TX queues per port. */
> >
> > queueid_t nb_rxq_bak = 1; /**< Backup of last correct number of RX
> > queues */
> > +queueid_t nb_txq_bak = 1; /**< Backup of last correct number of TX
> > +queues */
> >
> > /*
> > * Configurable number of RX/TX ring descriptors.
> > @@ -721,8 +722,12 @@ init_fwd_streams(void)
> > }
> > if (nb_txq > port->dev_info.max_tx_queues) {
> > printf("Fail: nb_txq(%d) is greater than "
> > - "max_tx_queues(%d)\n", nb_txq,
> > - port->dev_info.max_tx_queues);
> > + "max_tx_queues(%d), restored to backup "
> > + "txq number(%d)\n", nb_txq,
> > + port->dev_info.max_tx_queues,
> > + nb_txq_bak);
> > + /* restored to last correct nb_txq */
> > + nb_txq = nb_txq_bak;
> > return -1;
> > }
> > if (numa_support) {
> > @@ -744,8 +749,9 @@ init_fwd_streams(void)
> > }
> > }
> >
> > - /* backup the correct nb_rxq */
> > + /* backup the correct nb_rxq and nb_txq */
> > nb_rxq_bak = nb_rxq;
> > + nb_txq_bak = nb_txq;
> >
> > q = RTE_MAX(nb_rxq, nb_txq);
> > if (q == 0) {
> > diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index
> > 6f7932d..bca93c1 100644
> > --- a/app/test-pmd/testpmd.h
> > +++ b/app/test-pmd/testpmd.h
> > @@ -393,6 +393,7 @@ extern queueid_t nb_rxq; extern queueid_t
> nb_txq;
> >
> > extern queueid_t nb_rxq_bak;
> > +extern queueid_t nb_txq_bak;
> >
> > extern uint16_t nb_rxd;
> > extern uint16_t nb_txd;
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number setting
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Wednesday, January 10, 2018 9:55 AM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Wu, Jingjing ; Peng, Yuan
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number
> setting
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, January 10, 2018 1:34 AM
> > To: Ananyev, Konstantin ; Lu, Wenzhuo
> > ; Wu, Jingjing ; Peng,
> > Yuan
> > Cc: dev@dpdk.org; sta...@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq
> > number setting
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Tuesday, January 9, 2018 4:06 AM
> > > To: Dai, Wei ; Lu, Wenzhuo
> > > ; Wu, Jingjing ; Peng,
> > > Yuan
> > > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > > Subject: RE: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq
> > > number setting
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > > > Sent: Monday, January 8, 2018 1:03 PM
> > > > To: Lu, Wenzhuo ; Wu, Jingjing
> > > > ; Peng, Yuan
> > > > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > > > Subject: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq
> > > > number setting
> > > >
> > > > If an invalid RX queue is configured from testpmd command like
> > > > "port config all rxq number", the global variable rxq is updated
> > > > by this invalid value. It may cause testpmd crash.
> > > > This patch restores its last correct value when an invalid rxq
> > > > number configured is detected.
> > > >
> > > > Fixes: ce8d561418d4 ("app/testpmd: add port configuration
> > > > settings")
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Wei Dai
> > > > ---
> > > > app/test-pmd/cmdline.c | 1 +
> > > > app/test-pmd/testpmd.c | 10 -- app/test-pmd/testpmd.h
> |
> > > 2
> > > > ++
> > > > 3 files changed, 11 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > > > f71d963..3f3986c 100644
> > > > --- a/app/test-pmd/cmdline.c
> > > > +++ b/app/test-pmd/cmdline.c
> > > > @@ -1501,6 +1501,7 @@ cmd_config_rx_tx_parsed(void
> *parsed_result,
> > > > printf("Warning: Either rx or tx queues should
> > > > be non
> zero\n");
> > > > return;
> > > > }
> > > > + nb_rxq_bak = nb_rxq;
> > > > nb_rxq = res->value;
> > > > }
> > > > else if (!strcmp(res->name, "txq")) { diff --git
> > > > a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > > > 47e145c..5939c88 100644
> > > > --- a/app/test-pmd/testpmd.c
> > > > +++ b/app/test-pmd/testpmd.c
> > > > @@ -188,6 +188,8 @@ 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. */
> > > >
> > > > +queueid_t nb_rxq_bak = 1; /**< Backup of last correct number of
> > > > +RX queues */
> > > > +
> > > > /*
> > > > * Configurable number of RX/TX ring descriptors.
> > > > */
> > > > @@ -708,10 +710,14 @@ init_fwd_streams(void)
> > > > port = &ports[pid];
> > > > if (nb_rxq > port->dev_info.max_rx_queues) {
> > >
> > > Why not to add that check in the function handler for " port config ...
> rxq ..."
> > > command itself?
> > > In that case you wouldn't need nb_rxq_bak at all.
> > > Konstantin
> >
> > Thanks for your feedback, Konstantin.
> > I see your point. If that check is added in the function handler of
> > command line, same loop code will be repeated.
> >
> > There are 2 ways to change nb_rxq:
> > 1. with --rxq in the command line to start testpmd app to overwrite
> > the default value 1 2. with "port config all rxq number" in the
> > testpmd run time command li
Re: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number setting
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, January 9, 2018 4:06 AM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Wu, Jingjing ; Peng, Yuan
> Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> Subject: RE: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number
> setting
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Monday, January 8, 2018 1:03 PM
> > To: Lu, Wenzhuo ; Wu, Jingjing
> > ; Peng, Yuan
> > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > Subject: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number
> > setting
> >
> > If an invalid RX queue is configured from testpmd command like "port
> > config all rxq number", the global variable rxq is updated by this
> > invalid value. It may cause testpmd crash.
> > This patch restores its last correct value when an invalid rxq number
> > configured is detected.
> >
> > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 1 +
> > app/test-pmd/testpmd.c | 10 -- app/test-pmd/testpmd.h |
> 2
> > ++
> > 3 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > f71d963..3f3986c 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -1501,6 +1501,7 @@ cmd_config_rx_tx_parsed(void *parsed_result,
> > printf("Warning: Either rx or tx queues should be non
> > zero\n");
> > return;
> > }
> > + nb_rxq_bak = nb_rxq;
> > nb_rxq = res->value;
> > }
> > else if (!strcmp(res->name, "txq")) { diff --git
> > a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > 47e145c..5939c88 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -188,6 +188,8 @@ 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. */
> >
> > +queueid_t nb_rxq_bak = 1; /**< Backup of last correct number of RX
> > +queues */
> > +
> > /*
> > * Configurable number of RX/TX ring descriptors.
> > */
> > @@ -708,10 +710,14 @@ init_fwd_streams(void)
> > port = &ports[pid];
> > if (nb_rxq > port->dev_info.max_rx_queues) {
>
> Why not to add that check in the function handler for " port config ... rxq
> ..."
> command itself?
> In that case you wouldn't need nb_rxq_bak at all.
> Konstantin
Thanks for your feedback, Konstantin.
I see your point. If that check is added in the function handler of command
line,
same loop code will be repeated.
There are 2 ways to change nb_rxq:
1. with --rxq in the command line to start testpmd app to overwrite the default
value 1
2. with "port config all rxq number" in the testpmd run time command line
How can your method correct an invalid input with --rxq in the command to start
testpm app ?
By the way, my v1 patch has a bug in case of more than 1 port with different
maximum number of Rx queues.
For example, the max_rx_queues of port 0 is 8 and that of port 1 is 4.
The previous valid rxq=4, if "port config all rxq 5" is run,
The nb_rxq_bak is updated to 5, nb_rxq can't be restored to last correct value
4 for port 1.
I will fix bug in my v2 patch.
>
> > printf("Fail: nb_rxq(%d) is greater than "
> > - "max_rx_queues(%d)\n", nb_rxq,
> > - port->dev_info.max_rx_queues);
> > + "max_rx_queues(%d), restore to backup "
> > + "rxq number(%d)\n", nb_rxq,
> > + port->dev_info.max_rx_queues,
> > + nb_rxq_bak);
> > + nb_rxq = nb_rxq_bak;
> > return -1;
> > }
> > + nb_rxq_bak = nb_rxq;
> > if (nb_txq > port->dev_info.max_tx_queues) {
> > printf("Fail: nb_txq(%d) is greater than "
> > "max_tx_queues(%d)\n", nb_txq,
> > diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index
> > 4d7f27c..84246f7 100644
> > --- a/app/test-pmd/testpmd.h
> > +++ b/app/test-pmd/testpmd.h
> > @@ -391,6 +391,8 @@ extern uint64_t rss_hf; extern queueid_t nb_rxq;
> > extern queueid_t nb_txq;
> >
> > +extern queueid_t nb_rxq_bak;
> > +
> > extern uint16_t nb_rxd;
> > extern uint16_t nb_txd;
> >
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v9] net/i40e: determine number of queues per VF during run time
Thanks to Helin and Ferruh, I will submit v10 patch following your guide. > -Original Message- > From: Zhang, Helin > Sent: Monday, January 8, 2018 2:01 PM > To: Dai, Wei ; Wu, Jingjing ; > Xing, Beilei > Cc: dev@dpdk.org > Subject: RE: [PATCH v9] net/i40e: determine number of queues per VF during > run time > > > > > -----Original Message- > > From: Dai, Wei > > Sent: Tuesday, December 26, 2017 11:25 PM > > To: Wu, Jingjing; Xing, Beilei; Zhang, Helin > > Cc: dev@dpdk.org; Dai, Wei > > Subject: [PATCH v9] net/i40e: determine number of queues per VF during > > run time > > > > Without this patch, the number of queues per i40e VF is defined as 4 > > by > > CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4 in > config/common_base. > > It is fixed value determined in building time and can't be changed > > during run time. > > With this patch, the number of queues per i40e VF can be determinated > > during run time. For example, if the PCI address of an i40e PF is > > :bb.cc, with the EAL parameter -w :bb.cc,queue-num-per-vf=8 , > > the number of queues per VF created from this PF is 8. > > If there is no "queue-num-per-vf" setting in EAL parameters, it is 4 > > by default as before. And if the value after the "queue-num-per-vf" > > is invalid, it is set as 4 forcibly. The valid values include 1, 2, 4, 8, > > 16 . > > > > Signed-off-by: Wei Dai > > Acked-by: Konstantin Ananyev > > --- > > v9: > > v9 = v8+v7, is a complete version for maintainer's convenience. > > v8: > > As v7 patch has been accepted into dpdk-next-net-intel, this patch > > is based on v7 patch. > > add description in i40e document > > fix the last member of valid_keys[] for rte_kvargs_parse( ) > > add RTE_PMD_REGISTER_PARAM_STRING for this feature > > v7: > > use the macro instead of natural number > > correct git log message as the EAL parameter is only valid for PF > > v6: > > fix a small bug when detecting end character of strtoul > > v5: > > fix git log message and WARNING of coding stype > > v4: > > use rte_kvargs instead of pervious parsing function; > > use malloc/free instead of rte_zmalloc/rte_free. > > v3: > > fix WARNING of coding style issues from checkpa...@dpdk.org > > v2: > > fix WARNING of coding style issues from checkpa...@dpdk.org > > --- > > config/common_base | 1 - > > doc/guides/nics/i40e.rst | 12 --- > > drivers/net/i40e/i40e_ethdev.c | 75 > > +++--- > > 3 files changed, 78 insertions(+), 10 deletions(-) > > BTW, I think release notes should be updated for your modifications.
Re: [dpdk-dev] [PATCH v4 1/2] net/e1000: move RSS to flow API
> -Original Message- > From: Zhao1, Wei > Sent: Thursday, January 4, 2018 3:46 PM > To: dev@dpdk.org > Cc: Dai, Wei ; Zhao1, Wei > Subject: [PATCH v4 1/2] net/e1000: move RSS to flow API > > Rte_flow actually defined to include RSS, but till now, RSS is out of > rte_flow. > This patch is to move igb existing RSS to rte_flow. > The old RSS configuration is still reserved. > > Signed-off-by: Wei Zhao Acked-by: Wei Dai > --- > doc/guides/rel_notes/release_18_02.rst | 6 ++ > drivers/net/e1000/e1000_ethdev.h | 20 + > drivers/net/e1000/igb_ethdev.c | 17 > drivers/net/e1000/igb_flow.c | 160 > + > drivers/net/e1000/igb_rxtx.c | 61 + > 5 files changed, 264 insertions(+) >
Re: [dpdk-dev] [PATCH v4 2/2] net/ixgbe: move RSS to flow API
> -Original Message- > From: Zhao1, Wei > Sent: Thursday, January 4, 2018 3:46 PM > To: dev@dpdk.org > Cc: Dai, Wei ; Zhao1, Wei > Subject: [PATCH v4 2/2] net/ixgbe: move RSS to flow API > > Rte_flow actually defined to include RSS, but till now, RSS is out of > rte_flow. > This patch is to move ixgbe existing RSS to rte_flow. > The old RSS configuration is still reserved. > > Signed-off-by: Wei Zhao Acked-by: Wei Dai > --- > doc/guides/rel_notes/release_18_02.rst | 6 +- > drivers/net/ixgbe/ixgbe_ethdev.c | 13 +++ > drivers/net/ixgbe/ixgbe_ethdev.h | 10 ++ > drivers/net/ixgbe/ixgbe_flow.c | 165 > + > drivers/net/ixgbe/ixgbe_rxtx.c | 65 + > 5 files changed, 256 insertions(+), 3 deletions(-) >
Re: [dpdk-dev] [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
According to step 7 & 8 in Table 7-74 PF-to-VF Messaging Flow in 82599
datasheet,
The calling of ixgbe_read_mbx( ) can be replaced by following lines to avoid
touching ->mbx.v2p_mailbox,
IXGBE_WRITE_REG(hw, IXGBE_VFMAILBOX, IXGBE_VFMAILBOX_ACK);
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, December 28, 2017 4:22 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Dai, Wei ; Wang, Liang-min
> ; Zhang, Qi Z ;
> sta...@dpdk.org
> Subject: [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
>
> Mailbox interrupt handler only take care of PF reset notification, for other
> message ixgbe_read_mbx should not be called since it get chance to break
> the foreground VF to PF communication.
> This can be simply repeated by
> testpmd>rx_vlan rm all 0
>
> Fixes: 77234603fba0 ("net/ixgbe: support VF mailbox interrupt for link
> up/down")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ff19a56..02121f4 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -8165,13 +8165,17 @@ static void ixgbevf_mbx_process(struct
> rte_eth_dev *dev)
> struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> u32 in_msg = 0;
>
> - if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> - return;
> + /* peek the message first */
> + in_msg = IXGBE_READ_REG(hw, IXGBE_VFMBMEM);
>
> /* PF reset VF event */
> - if (in_msg == IXGBE_PF_CONTROL_MSG)
> + if (in_msg == IXGBE_PF_CONTROL_MSG) {
> + /* dummy mbx read to ack pf */
> + if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> + return;
> _rte_eth_dev_callback_process(dev,
> RTE_ETH_EVENT_INTR_RESET,
> NULL, NULL);
> + }
> }
>
> static int
> --
> 2.7.4
Re: [dpdk-dev] [PATCH] igb: fix Tx queue number
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of zhouyangchao
> Sent: Wednesday, November 29, 2017 10:50 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo
> Subject: [dpdk-dev] [PATCH] igb: fix Tx queue number
>
> Internal variable containing the number of TX queues for a device, was being
> incorrectly assigned the number of RX queues, instead of TX.
>
> Fixes: 27b609cbd1c6 ("ethdev: move the multi-queue mode check to specific
> drivers")
>
> Signed-off-by: Yangchao Zhou
Acked-by: Wei Dai
> ---
> drivers/net/e1000/igb_ethdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/e1000/igb_ethdev.c
> b/drivers/net/e1000/igb_ethdev.c index fdc139f..a600fba 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -1212,7 +1212,7 @@ igb_check_mq_mode(struct rte_eth_dev *dev)
> enum rte_eth_rx_mq_mode rx_mq_mode =
> dev->data->dev_conf.rxmode.mq_mode;
> enum rte_eth_tx_mq_mode tx_mq_mode =
> dev->data->dev_conf.txmode.mq_mode;
> uint16_t nb_rx_q = dev->data->nb_rx_queues;
> - uint16_t nb_tx_q = dev->data->nb_rx_queues;
> + uint16_t nb_tx_q = dev->data->nb_tx_queues;
>
> if ((rx_mq_mode & ETH_MQ_RX_DCB_FLAG) ||
> tx_mq_mode == ETH_MQ_TX_DCB ||
> --
> 2.9.0.windows.1
>
>
Re: [dpdk-dev] [PATCH v6] net/i40e: determine number of queues per VF during run time
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Sunday, December 3, 2017 7:20 PM
> To: Dai, Wei ; Wu, Jingjing ;
> Xing, Beilei
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v6] net/i40e: determine number of queues per VF during
> run time
>
> Hi Wei,
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Monday, November 27, 2017 8:09 AM
> > To: Wu, Jingjing ; Xing, Beilei
> > ; Ananyev, Konstantin
> >
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v6] net/i40e: determine number of queues per VF during
> > run time
> >
> > Without this patch, the number of queues per i40e VF is defined as 4
> > by CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4 in
> config/common_base.
> > It is fixed value determined in building time and can't be changed
> > during run time.
> > With this patch, the number of queues per i40e VF can be determinated
> > during run time. For example, if the PCI address of an i40e VF is
Here it should be 'if the PCI address of an i40e PF is'
I will correct it in my v7 patch.
> > :bb.cc, with the EAL parameter -w :bb.cc,queue-num-per-vf=8,
> > the number of queues per VF is 8.
> > If there is no "queue-num-per-vf" setting in EAL parameters, it is 4
> > by default as before. And if the value after the "queue-num-per-vf"
> > is invalid, it is set as 4 forcibly. The valid values include 1, 2, 4,
> > 8, 16 .
> >
> > Signed-off-by: Wei Dai
> >
> > ---
> > v6:
> > fix a small bug when detecting end character of strtoul
> > v5:
> > fix git log message and WARNING of coding stype
> > v4:
> > use rte_kvargs instead of pervious parsing function;
> > use malloc/free instead of rte_zmalloc/rte_free.
> > v3:
> > fix WARNING of coding style issues from checkpa...@dpdk.org
> > v2:
> > fix WARNING of coding style issues from checkpa...@dpdk.org
> > ---
> > config/common_base | 1 -
> > drivers/net/i40e/i40e_ethdev.c | 67
> > --
> > 2 files changed, 65 insertions(+), 3 deletions(-)
> >
> > + if (errno != 0 || end == value || *end != 0) {
> > + PMD_DRV_LOG(WARNING, "Wrong VF queue number = %s, Now it
> is "
> > + "kept the value = %hu", value, pf->vf_nb_qp_max);
> > + return -(EINVAL);
> > + }
> > +
> > + if (num <= 16 && rte_is_power_of_2(num))
>
> As a nit - better to use some macro instead of '16' here.
> Apart from that - looks good to me.
> Acked-by: Konstantin Ananyev
Thanks for your Ack, Konstantin.
I will use the macro I40E_MAX_QP_NUM_PER_VF instead of 16 in my v7 patch.
This macro is already defined as 16 in i40e_ethdev.h
>
> > + pf->vf_nb_qp_max = (uint16_t)num;
> > + else
> > + /* here return 0 to make next valid same argument work */
> > + PMD_DRV_LOG(WARNING, "Wrong VF queue number = %lu, it
> must be "
> > + "power of 2 and equal or less than 16 !, Now it is "
> > + "kept the value = %hu", num, pf->vf_nb_qp_max);
> > +
> > + return 0;
> > +}
Re: [dpdk-dev] [PATCH v3 2/2] net/ixgbe: move RSS to flow API
Hi, Zhao Wei
Please correct build error show in
http://dpdk.org/ml/archives/test-report/2017-November/035130.html
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Friday, November 24, 2017 4:05 PM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: [dpdk-dev] [PATCH v3 2/2] net/ixgbe: move RSS to flow API
>
> Rte_flow actually defined to include RSS, but till now, RSS is out of
> rte_flow.
> This patch is to move ixgbe existing RSS to rte_flow.
>
> Signed-off-by: Wei Zhao
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 13 +++
> drivers/net/ixgbe/ixgbe_ethdev.h | 10 +++
> drivers/net/ixgbe/ixgbe_flow.c | 165
> +++
> drivers/net/ixgbe/ixgbe_rxtx.c | 65 +++
> 4 files changed, 253 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ff19a56..4960650 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -8339,6 +8339,18 @@ ixgbe_l2_tn_filter_restore(struct rte_eth_dev
> *dev)
> }
> }
>
> +/* restore rss filter */
> +static inline void
> +ixgbe_rss_filter_restore(struct rte_eth_dev *dev) {
> + struct ixgbe_filter_info *filter_info =
> + IXGBE_DEV_PRIVATE_TO_FILTER_INFO(dev->data->dev_private);
> +
> + if (filter_info->rss_info.num)
> + ixgbe_config_rss_filter(dev,
> + &filter_info->rss_info, TRUE);
> +}
> +
> static int
> ixgbe_filter_restore(struct rte_eth_dev *dev) { @@ -8347,6 +8359,7 @@
> ixgbe_filter_restore(struct rte_eth_dev *dev)
> ixgbe_syn_filter_restore(dev);
> ixgbe_fdir_filter_restore(dev);
> ixgbe_l2_tn_filter_restore(dev);
> + ixgbe_rss_filter_restore(dev);
>
> return 0;
> }
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h
> b/drivers/net/ixgbe/ixgbe_ethdev.h
> index 51ddcfd..4af79b4 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.h
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.h
> @@ -224,6 +224,12 @@ struct ixgbe_hw_fdir_info {
> bool mask_added; /* If already got mask from consistent filter */ };
>
> +struct ixgbe_rte_flow_rss_conf {
> + struct rte_eth_rss_conf rss_conf; /**< RSS parameters. */
> + uint16_t num; /**< Number of entries in queue[]. */
> + uint16_t queue[IXGBE_MAX_RX_QUEUE_NUM]; /**< Queues indices to
> use. */
> +};
> +
> /* structure for interrupt relative data */ struct ixgbe_interrupt {
> uint32_t flags;
> @@ -340,6 +346,8 @@ struct ixgbe_filter_info {
> struct ixgbe_5tuple_filter_list fivetuple_list;
> /* store the SYN filter info */
> uint32_t syn_info;
> + /* store the rss filter info */
> + struct ixgbe_rte_flow_rss_conf rss_info;
> };
>
> struct ixgbe_l2_tn_key {
> @@ -719,6 +727,8 @@ void ixgbe_tm_conf_init(struct rte_eth_dev *dev);
> void ixgbe_tm_conf_uninit(struct rte_eth_dev *dev); int
> ixgbe_set_queue_rate_limit(struct rte_eth_dev *dev, uint16_t queue_idx,
> uint16_t tx_rate);
> +int ixgbe_config_rss_filter(struct rte_eth_dev *dev,
> + struct ixgbe_rte_flow_rss_conf *conf, bool add);
>
> static inline int
> ixgbe_ethertype_filter_lookup(struct ixgbe_filter_info *filter_info, diff
> --git
> a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c index
> 19c2d47..8f964cf 100644
> --- a/drivers/net/ixgbe/ixgbe_flow.c
> +++ b/drivers/net/ixgbe/ixgbe_flow.c
> @@ -103,6 +103,11 @@ struct ixgbe_eth_l2_tunnel_conf_ele {
> TAILQ_ENTRY(ixgbe_eth_l2_tunnel_conf_ele) entries;
> struct rte_eth_l2_tunnel_conf filter_info; };
> +/* rss filter list structure */
> +struct ixgbe_rss_conf_ele {
> + TAILQ_ENTRY(ixgbe_rss_conf_ele) entries;
> + struct ixgbe_rte_flow_rss_conf filter_info; };
> /* ixgbe_flow memory list structure */
> struct ixgbe_flow_mem {
> TAILQ_ENTRY(ixgbe_flow_mem) entries;
> @@ -114,6 +119,7 @@ TAILQ_HEAD(ixgbe_ethertype_filter_list,
> ixgbe_ethertype_filter_ele); TAILQ_HEAD(ixgbe_syn_filter_list,
> ixgbe_eth_syn_filter_ele); TAILQ_HEAD(ixgbe_fdir_rule_filter_list,
> ixgbe_fdir_rule_ele); TAILQ_HEAD(ixgbe_l2_tunnel_filter_list,
> ixgbe_eth_l2_tunnel_conf_ele);
> +TAILQ_HEAD(ixgbe_rss_filter_list, ixgbe_rss_conf_ele);
> TAILQ_HEAD(ixgbe_flow_mem_list, ixgbe_flow_mem);
>
> static struct ixgbe_ntuple_filter_list filter_ntuple_list; @@ -121,6 +127,7
> @@ static struct ixgbe_ethertype_filter_list filter_ethertype_list; static
> struct ixgbe_syn_filter_list filter_syn_list; static struct
> ixgbe_fdir_rule_filter_list filter_fdir_list; static struct
> ixgbe_l2_tunnel_filter_list filter_l2_tunnel_list;
> +static struct ixgbe_rss_filter_list filter_rss_list;
> static struct ixgbe_flow_mem_list ixgbe_flow_list;
>
> /**
> @@ -2700,6 +2707,109 @@ ixgbe_parse_fdir_filter(struct rte_eth_dev
> *dev,
> return ret;
> }
>
> +static int
> +ixgbe_parse_rss_filter(struct rte_eth_dev *dev,
> + const struct rte_flow_attr *att
Re: [dpdk-dev] [PATCH v3 1/2] net/e1000: move RSS to flow API
Hi, Zhao Wei
Please correct build error show in
http://dpdk.org/ml/archives/test-report/2017-November/035129.html
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Friday, November 24, 2017 4:05 PM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: [dpdk-dev] [PATCH v3 1/2] net/e1000: move RSS to flow API
>
> Rte_flow actually defined to include RSS, but till now, RSS is out of
> rte_flow.
> This patch is to move igb existing RSS to rte_flow.
>
> Signed-off-by: Wei Zhao
> ---
> drivers/net/e1000/e1000_ethdev.h | 20 +
> drivers/net/e1000/igb_ethdev.c | 17 +
> drivers/net/e1000/igb_flow.c | 160
> +++
> drivers/net/e1000/igb_rxtx.c | 61 +++
> 4 files changed, 258 insertions(+)
>
> diff --git a/drivers/net/e1000/e1000_ethdev.h
> b/drivers/net/e1000/e1000_ethdev.h
> index 5668910..0731766 100644
> --- a/drivers/net/e1000/e1000_ethdev.h
> +++ b/drivers/net/e1000/e1000_ethdev.h
> @@ -257,6 +257,12 @@ struct igb_ethertype_filter {
> uint32_t etqf;
> };
>
> +struct igb_rte_flow_rss_conf {
> + struct rte_eth_rss_conf rss_conf; /**< RSS parameters. */
> + uint16_t num; /**< Number of entries in queue[]. */
> + uint16_t queue[IGB_MAX_RX_QUEUE_NUM]; /**< Queues indices to
> use. */
> +};
> +
> /*
> * Structure to store filters'info.
> */
> @@ -274,6 +280,8 @@ struct e1000_filter_info {
> struct e1000_2tuple_filter_list twotuple_list;
> /* store the SYN filter info */
> uint32_t syn_info;
> + /* store the rss filter info */
> + struct igb_rte_flow_rss_conf rss_info;
> };
>
> /*
> @@ -342,6 +350,12 @@ struct igb_flex_filter_ele {
> struct rte_eth_flex_filter filter_info; };
>
> +/* rss filter list structure */
> +struct igb_rss_conf_ele {
> + TAILQ_ENTRY(igb_rss_conf_ele) entries;
> + struct igb_rte_flow_rss_conf filter_info; };
> +
> /* igb_flow memory list structure */
> struct igb_flow_mem {
> TAILQ_ENTRY(igb_flow_mem) entries;
> @@ -357,6 +371,8 @@ TAILQ_HEAD(igb_syn_filter_list,
> igb_eth_syn_filter_ele); struct igb_syn_filter_list igb_filter_syn_list;
> TAILQ_HEAD(igb_flex_filter_list, igb_flex_filter_ele); struct
> igb_flex_filter_list igb_filter_flex_list;
> +TAILQ_HEAD(igb_rss_filter_list, igb_rss_conf_ele); struct
> +igb_rss_filter_list igb_filter_rss_list;
> TAILQ_HEAD(igb_flow_mem_list, igb_flow_mem); struct
> igb_flow_mem_list igb_flow_list;
>
> @@ -500,4 +516,8 @@ int eth_igb_syn_filter_set(struct rte_eth_dev *dev,
> int eth_igb_add_del_flex_filter(struct rte_eth_dev *dev,
> struct rte_eth_flex_filter *filter,
> bool add);
> +int igb_config_rss_filter(struct rte_eth_dev *dev,
> + struct igb_rte_flow_rss_conf *conf,
> + bool add);
> +
> #endif /* _E1000_ETHDEV_H_ */
> diff --git a/drivers/net/e1000/igb_ethdev.c
> b/drivers/net/e1000/igb_ethdev.c index fdc139f..275fa02 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -948,6 +948,7 @@ eth_igb_dev_init(struct rte_eth_dev *eth_dev)
> TAILQ_INIT(&igb_filter_ethertype_list);
> TAILQ_INIT(&igb_filter_syn_list);
> TAILQ_INIT(&igb_filter_flex_list);
> + TAILQ_INIT(&igb_filter_rss_list);
> TAILQ_INIT(&igb_flow_list);
>
> return 0;
> @@ -1007,6 +1008,10 @@ eth_igb_dev_uninit(struct rte_eth_dev *eth_dev)
> memset(filter_info->ethertype_filters, 0,
> E1000_MAX_ETQF_FILTERS * sizeof(struct igb_ethertype_filter));
>
> + /* clear the rss filter info */
> + memset(&filter_info->rss_info, 0,
> + sizeof(struct igb_rte_flow_rss_conf));
> +
> /* remove all ntuple filters of the device */
> igb_ntuple_filter_uninit(eth_dev);
>
> @@ -5628,6 +5633,17 @@ igb_flex_filter_restore(struct rte_eth_dev *dev)
> }
> }
>
> +/* restore rss filter */
> +static inline void
> +igb_rss_filter_restore(struct rte_eth_dev *dev) {
> + struct e1000_filter_info *filter_info =
> + E1000_DEV_PRIVATE_TO_FILTER_INFO(dev->data->dev_private);
> +
> + if (filter_info->rss_info.num)
> + igb_config_rss_filter(dev, &filter_info->rss_info, TRUE); }
> +
> /* restore all types filter */
> static int
> igb_filter_restore(struct rte_eth_dev *dev) @@ -5636,6 +5652,7 @@
> igb_filter_restore(struct rte_eth_dev *dev)
> igb_ethertype_filter_restore(dev);
> igb_syn_filter_restore(dev);
> igb_flex_filter_restore(dev);
> + igb_rss_filter_restore(dev);
>
> return 0;
> }
> diff --git a/drivers/net/e1000/igb_flow.c b/drivers/net/e1000/igb_flow.c
> index 22bad26..bf5cfac 100644
> --- a/drivers/net/e1000/igb_flow.c
> +++ b/drivers/net/e1000/igb_flow.c
> @@ -1295,6 +1295,101 @@ igb_parse_flex_filter(struct rte_eth_dev *dev,
> return 0;
> }
>
> +static int
> +igb_parse_rss_filter(struct rte_eth_dev *dev,
> + con
Re: [dpdk-dev] [PATCH v3] net/i40e: determine number of queues per VF during run time
Thank you, Konstantin for your quick feedback.
Please see my inline comments below.
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Monday, November 20, 2017 7:32 PM
> To: Dai, Wei ; Wu, Jingjing ;
> Xing, Beilei
> Cc: dev@dpdk.org; Dai, Wei
> Subject: RE: [dpdk-dev] [PATCH v3] net/i40e: determine number of queues
> per VF during run time
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Sunday, November 19, 2017 2:08 PM
> > To: Wu, Jingjing ; Xing, Beilei
> >
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [dpdk-dev] [PATCH v3] net/i40e: determine number of queues
> > per VF during run time
> >
> > Without this patch, the number of queues per i40e VF is defined as 4
> > by CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4 in
> config/common_base.
> > It is fixed value determined in building time and can't be changed
> > during run time.
> > With this patch, the number of queues per i40e VF can be determinated
> > during run time. For example, if the PCI address of an i40e VF is
> > :bb.cc, with the EAL parameter -w
> > :bb.cc,i40e-queue-num-per-vf=8
> > , the number of queues per VF is 8.
> > If there is no "i40e-queue-num-per-vf" setting in EAL parameters, it
> > is 4 by default as before. And if the value after the
> > "i40e-queue-num-per-vf" is invalid, it is set as 4 forcibly.
> > The valid values include 1, 2, 4, 8, 16 .
> >
> > Signed-off-by: Wei Dai
> >
> > ---
> > v3: fix WARNING of coding style issues from checkpa...@dpdk.org
> > v2: fix WARNING of coding style issues from checkpa...@dpdk.org
> > ---
> > config/common_base | 1 -
> > drivers/net/i40e/i40e_ethdev.c | 67
> > --
> > 2 files changed, 65 insertions(+), 3 deletions(-)
> >
> > diff --git a/config/common_base b/config/common_base index
> > e74febe..4e20389 100644
> > --- a/config/common_base
> > +++ b/config/common_base
> > @@ -208,7 +208,6 @@
> CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
> > CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
> > CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
> > CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
> > -CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
> > CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
> > # interval up to 8160 us, aligned to 2 (or default value)
> > CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 811cc9f..b23a39e 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -3971,6 +3971,67 @@ i40e_get_cap(struct i40e_hw *hw)
> > return ret;
> > }
> >
> > +static int i40e_pf_config_vf_rxq_number(struct rte_eth_dev *dev) {
> > +#define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF 4
> > +#define I40E_QUEUE_NUM_PER_VF_ARG
> "i40e-queue-num-per-vf"
>
> Does it need to have i40e prefix?
> Provably other HW type would support similar devarg?
Yes, I can't be sure if other HW type support this.
Will remove i40e prefix in next version of patch.
>
> > +
> > + struct i40e_pf *pf =
> I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> > + char *s;
> > + char *ps0, *ps1, *pv;
> > + char *end;
> > + unsigned long value;
> > +
> > + if (!is_i40e_supported(dev))
> > + return -ENOTSUP;
>
> Not a big deal - but that function is static, so I suppose the check is
> redundant.
Yes, this is a static function, so it can't be called by other type of NIC.
I add this in order to prevent it being called by other NIC.
Now I see it is unnecessary. I will remove it in next version of patch.
>
> > +
> > + /* set default queue number per VF as 4 */
> > + pf->vf_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
> > +
> > + if (dev->device->devargs == NULL)
> > + return 0;
> > +
> > + s = rte_zmalloc(__func__, strlen(dev->device->devargs->args) + 1,
> > +0);
>
> No need to allocate temp memory from hugepages here.
> Normal malloc, or even alloca() would do, I think.
Yes, no need to allocate memory from hugepage.
I will use normal malloc/freee instead of rte_zmalloc/rte_free.
>
>
> > + if (s == NULL)
> > + return -(ENOMEM);
> > + strcpy(s, dev->device->devargs->args);
> > +
>
> What is the point to write your own parsing function from scratch?
> Why just not use rte_kvargs API as most other PMDs d
Re: [dpdk-dev] [PATCH] net/ixgbe: fix VF RX hang
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Monday, November 20, 2017 11:38 AM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] net/ixgbe: fix VF RX hang
>
> The datasheet says, if using MSI-X mode, the PBA support bit of the GPIE
> register must be set to 1.
> DPDK uses polling mode, we cannot hit this issue in the scenario DPDK PF +
> DPDK VF. If we use DPDK PF + kernel VF, as the kernel driver uses interrpt
> mode, VF may hit RX hang after running hours.
>
> Fixes: 00e30184daa0 ("ixgbe: add PF support")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wenzhuo Lu
Acked-by: Wei Dai
Thank you, Wenzhuo.
This bug-fix address to Rx hang after long time running.
It has also been confirmed by Intel NIC firmware team and tested by one of our
customers.
> ---
> drivers/net/ixgbe/ixgbe_pf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c index
> 676e92c..0114694 100644
> --- a/drivers/net/ixgbe/ixgbe_pf.c
> +++ b/drivers/net/ixgbe/ixgbe_pf.c
> @@ -273,7 +273,7 @@ int ixgbe_pf_host_configure(struct rte_eth_dev
> *eth_dev)
>
> gpie = IXGBE_READ_REG(hw, IXGBE_GPIE);
> gpie &= ~IXGBE_GPIE_VTMODE_MASK;
> - gpie |= IXGBE_GPIE_MSIX_MODE;
> + gpie |= IXGBE_GPIE_MSIX_MODE | IXGBE_GPIE_PBA_SUPPORT;
>
> switch (RTE_ETH_DEV_SRIOV(eth_dev).active) {
> case ETH_64_POOLS:
> --
> 1.9.3
Re: [dpdk-dev] [PATCH v3 0/2] Fix 2 bugs of i40e VF interrupt found in l3fwd-power
> -Original Message-
> From: Dai, Wei
> Sent: Friday, November 3, 2017 4:47 PM
> To: Wu, Jingjing ; Xing, Beilei
>
> Cc: dev@dpdk.org; Dai, Wei
> Subject: [PATCH v3 0/2] Fix 2 bugs of i40e VF interrupt found in l3fwd-power
>
> These 2 bugs can be observed from example/l3fwd-power run with i40e VF
> bound to VFIO-PCI. The test steps are as follows:
> 1. Disable LSC interrupt by clearing port_conf.intr_conf.lsc=0, as i40e
>VF doesn't support LSC interrupt to avoid rte_eth_dev_configure()
> failure.
> 2. Create a VF from i40e host PF. Let PF run with kernel driver and bind
>its VF to VFIO-PCI
> 3. Run l3fwd-power like: l3fwd-power -l 18-19 -- -p 0x1 --config='(0,0,19)'
>
> Then, the following error message appears like:
> EAL: Error enabling MSI-X interrupts for fd 18 This error is from
> rte_intr_enable( )/vfio_enable_msix( ) when enabling Rx queue interrupt.
> Same as the patch 06938770186a ("net/ixgbe: fix VFIO interrupt mapping in
> VF"), to change VFIO MSI-X interrupts mapping, previous mapping should be
> cleared first to avoid above error.
>
> After fixing above VFIO-PCI MSI-X interrupt mapping. There is still the
> following 2nd bug: l3fwd-power still can not be waked up by incoming
> packets.
>
> Same as the patch ca9d6597184b ("net/ixgbe: fix Rx queue interrupt
> mapping in VF"), the interrupt vector of Rx queues should be mapped to
> vector 1 to fix above 2nd bug.
>
> These patches have passed test with l3fwd-power using i40e VF bound to
> VFIO-PCI.
> They also passed the test with testpmd rxonly and txonly mode with igb_uio
> and VFIO-PCI.
>
> Signed-off-by: Wei Dai
> Tested-by: Lei Yao
>
> ---
> v3:
> keep rte_intr_enable( ) for safety and align the style with other PMD.
Keep rte_intr_enable( ) in i40evf_dev_rx_queue_intr_enable( ) for safety
And align the style with other PMD.
> remove 2 unsed macros.
>
> v2:
> only remap VFIO interrupt in i40evf_dev_start( )
>
> Wei Dai (2):
> net/i40e: fix VFIO interrupt mapping in VF
> net/i40e: fix Rx queue interrupt mapping in VF
>
> drivers/net/i40e/i40e_ethdev_vf.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> --
> 2.7.4
Re: [dpdk-dev] [PATCH 2/2] net/i40e: fix Rx queue interrupt mapping in VF
Hi, Jingjing
Thanks for your feedback.
> > Subject: [PATCH 2/2] net/i40e: fix Rx queue interrupt mapping in VF
> >
> > When a VF port is bound to VFIO-PCI, miscellaneous interrupt is mapped
> > to MSI-X vector 0 and Rx queues interrupt are mapped to other vectors
> > in vfio_enable_msix( ). To simplify implementation, all VFIO-PCI bound
> > i40e VF Rx queue interrupts can be mapped in vector 1. And as current
> > igb_uio only support only one vector, i40e VF PMD should use vector 0
> > for igb_uio and vector 1 for VFIO-PCI. Without this patch, VF Rx queue
> > interrupt is mapped to vector 0 in register settings and mapped to
> > VFIO vector 1 in vfio_enable_msix( ), and then all Rx queue interrupts will
> be missed.
> >
> > Fixes: 4b90a3ff26c5 ("i40evf: support Rx interrupt")
> > Fixes: 975ffea6f671 ("net/i40e: remove DPDK PF version specific code")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> > b/drivers/net/i40e/i40e_ethdev_vf.c
> > index 567b7d0..94fb4b1 100644
> > --- a/drivers/net/i40e/i40e_ethdev_vf.c
> > +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> > @@ -654,7 +654,7 @@ i40evf_config_irq_map(struct rte_eth_dev *dev)
> > int i, err;
> >
> > if (rte_intr_allow_others(intr_handle))
> > - vector_id = I40EVF_VSI_DEFAULT_MSIX_INTR_LNX;
> > + vector_id = I40EVF_VSI_DEFAULT_MSIX_INTR;
>
> Firstly, We can use I40E_MISC_VEC_ID and I40E_RX_VEC_START to replace
> I40EVF_VSI_DEFAULT_MSIX_INTR_LNX and
> I40EVF_VSI_DEFAULT_MSIX_INTR.
It looks good using I40E_RX_VEC_START instead of I40EVF_VSI_DEFAULT_MSIX_INTR.
>
> You need to check if rx interrupt is enabled or not, if not we should use
> I40E_MISC_VEC_ID.
> If rx interrupt is enabled, and rte_intr_allow_others(intr_handle) is true,
> then
> use I40E_RX_VEC_START.
Yes I have tested it and confirm Rx interrupt is enabled with l3fwd-power.
>
> And I think in VFIO cases, we can use more than one interrupt for the IRQ
> mapping. You can refer to the function i40e_vsi_queues_bind_intr.
>
Re: [dpdk-dev] [PATCH 1/2] net/i40e: fix VFIO interrupt mapping in VF
Hi, Jingjing
Thanks for your feedback.
> > Subject: [PATCH 1/2] net/i40e: fix VFIO interrupt mapping in VF
> >
> > When a VF port is bound to VFIO-PIC, only miscellaneous interrupt is
> > mapped to VFIO vector 0 in i40evf_dev_init( ).
> > In ixgbevf_dev_interrupt_handler( ), if previous VFIO interrupt
> > mapping set in
>
> Ixgbevf? Should be i40evf?
Yes, it is my typo error, it should be i40evf.
>
> > i40evf_dev_init( ) is not cleard, it will fail when calling
> > rte_intr_enable( ) tries to map Rx queue interrupt to other VFIO
> > vectors. This patch clears the VFIO interrupt mappings before setting
> > both miscellaneous and Rx queue interrupt mappings again to avoid
> failure.
> >
> > Fixes: 4b90a3ff26c5 ("i40evf: support Rx interrupt")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/i40e/i40e_ethdev_vf.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> > b/drivers/net/i40e/i40e_ethdev_vf.c
> > index 3b76c9e..567b7d0 100644
> > --- a/drivers/net/i40e/i40e_ethdev_vf.c
> > +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> > @@ -1432,8 +1432,9 @@ i40evf_dev_interrupt_handler(void *param)
> >" do nothing");
> >
> > done:
> > - i40evf_enable_irq0(hw);
> > + rte_intr_disable(dev->intr_handle);
> > rte_intr_enable(dev->intr_handle);
> > + i40evf_enable_irq0(hw);
>
> If that reason, you can move the rte_intr_disable to dev_start when deal
> with the rxq setting in intr_conf.
Yes, I have followed your suggestion and tested it with my following code
change.
it works well.
The function rte_intr_disable( ) can be moved into i40evf_dev_start( ) and only
be called it if rx queue interrupt is enabled.
Meanwhile, the calling of rte_intr_enable( ) in i40evf_dev_interrupt_handle( )
and i40evf_dev_rx_queue_intr_enable( ) can also be removed.
> > }
> >
> > static int
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix filter parser error in L2 tunnel
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Peng, Yuan
> Sent: Friday, November 3, 2017 11:39 AM
> To: Zhao1, Wei ; dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix filter parser error in L2
> tunnel
>
> Tested-by: Peng Yuan
>
> - Tested Branch: dpdk-master
> - Tested Commit: 8ced1542f7a356097c0b24bd1e08db670ff31b92
> - OS: 4.8.6-300.fc25.x86_64
> - GCC: gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
> - CPU: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz
> - NIC: Intel Corporation Ethernet Connection X552/X557-AT 10GBASE-T
> [8086:15ad]
> - Default x86_64-native-linuxapp-gcc configuration
> - Prerequisites:
> - Total 1 cases, 1 passed, 0 failed
>
> Hardware:
> dut: 10.240.176.192
> tester: 10.240.176.191
> X552/X557-AT 10g*2
>
> Test steps:
>
> Bind pf to igb_uio:
> ./usertools/dpdk-devbind.py -b igb_uio 03:00.0
>
> add two vfs on dpdk pf, then bind the vfs to vfio-pci:
> echo 2 >/sys/bus/pci/devices/:03:00.0/max_vfs
> ./usertools/dpdk-devbind.py -b vfio-pci 03:10.0 03:10.2
>
> Start testpmd:
> ./x86_64-native-linuxapp-gcc/app/testpmd -c 1f -n 4 -m 1024 -w 03:00.0
> --file-prefix=pf - -i --rxq=4 --txq=4 testpmd> set fwd rxonly testpmd> set
> verbose 1 testpmd> start ./x86_64-native-linuxapp-gcc/app/testpmd -c
> 0xf0 -n 4 -w 03:10.0 --file-prefix=vf0 -m 1024 - -i --rxq=4 --txq=4
> --disable-rss
> testpmd> set fwd rxonly testpmd> set verbose 1 testpmd>
> start ./x86_64-native-linuxapp-gcc/app/testpmd -c 0xf00 -n 4 -w 03:10.2
> --file-prefix=vf1 -m 1024 - -i --rxq=4 --txq=4 --disable-rss testpmd> set fwd
> rxonly testpmd> set verbose 1 testpmd> start
>
> 1. create filter rules,
> testpmd> flow create 0 ingress pattern e_tag grp_ecid_b is 0x1309 / end
> actions vf id 0 / end Flow rule #0 created testpmd> flow create 0 ingress
> pattern e_tag grp_ecid_b is 0x1308 / end actions vf id 1 / end Flow rule #1
> created
>
> 2. send packets:
> pkt1 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1,
> ECIDbase=0x309)/Raw('x' * 20)
> pkt2 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1,
> ECIDbase=0x308)/Raw('x' * 20)
> pkt3 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x1,
> ECIDbase=0x307)/Raw('x' * 20)
> pkt4 = Ether(dst="00:11:22:33:44:55")/Dot1BR(GRP=0x2,
> ECIDbase=0x309)/Raw('x' * 20)
>
> verify pkt1 to vf0 queue0, pkt2 to vf1 queue0, pkt3 and pkt4 can't received
> by pf and vfs.
>
>
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Wednesday, November 1, 2017 4:25 PM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: [dpdk-dev] [PATCH v2] net/ixgbe: fix filter parser error in L2 tunnel
>
> The action for L2 tunnel should be VF, not QUEUE.
>
> Fixes: 99e7003831c ("net/ixgbe: parse L2 tunnel filter")
>
> Signed-off-by: Wei Zhao
Acked-by: Wei Dai
> ---
> drivers/net/ixgbe/ixgbe_flow.c | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_flow.c b/drivers/net/ixgbe/ixgbe_flow.c
> index 82fc705..1c5e103 100644
> --- a/drivers/net/ixgbe/ixgbe_flow.c
> +++ b/drivers/net/ixgbe/ixgbe_flow.c
> @@ -1095,7 +1095,7 @@ ixgbe_parse_syn_filter(struct rte_eth_dev *dev,
> * The first not void item can be E_TAG.
> * The next not void item must be END.
> * action:
> - * The first not void action should be QUEUE.
> + * The first not void action should be VF.
> * The next not void action should be END.
> * pattern example:
> * ITEM SpecMask
> @@ -1116,7 +1116,7 @@ cons_parse_l2_tn_filter(const struct
> rte_flow_attr *attr,
> const struct rte_flow_item_e_tag *e_tag_spec;
> const struct rte_flow_item_e_tag *e_tag_mask;
> const struct rte_flow_action *act;
> - const struct rte_flow_action_queue *act_q;
> + const struct rte_flow_action_vf *act_vf;
>
> if (!pattern) {
> rte_flow_error_set(error, EINVAL,
> @@ -1224,9 +1224,9 @@ cons_parse_l2_tn_filter(const struct
> rte_flow_attr *attr,
> return -rte_errno;
> }
>
> - /* check if the first not void action is QUEUE. */
> + /* check if the first not void action is VF. */
> act = next_no_void_action(actions, NULL);
> - if (act->type != RTE_FLOW_ACTION_TYPE_QUEUE) {
> + if (act->type != RTE_FLOW_ACTION_TYPE_VF) {
> memset(filter, 0, sizeof(struct rte_eth_l2_tunnel_conf));
> rte_flow_error_set(error, EINVAL,
> RTE_FLOW_ERROR_TYPE_ACTION,
> @@ -1234,8 +1234,8 @@ cons_parse_l2_tn_filter(const struct
> rte_flow_attr *attr,
> return -rte_errno;
> }
>
> - act_q = (const struct rte_flow_action_queue *)act->conf;
> - filter->pool = act_q->index;
> + act_vf = (const struct rte_flow_action_vf *)act->conf;
> + filter->pool = act_vf->id;
>
> /* check if the next not void item is END */
> act = next_no_void_action(actions, act); @@ -1260,6 +1260,8 @@
> ixgbe_parse_l
Re: [dpdk-dev] [PATCH 0/3] RFC: implement VF reset for i40e, e1000 and ixgbe
Current rte_eth_dev_reset( ) from my patches are just to reset the NIC port,
NOT recovery its traffic.
All my patches for NIC reset have already been accepted.
It is the duty of user application to recovery any settings and traffic by
going through rte_eth_dev_configure(...),
rte_eth_rx_queue_setup(...)/rte_eth_tx_queue_setup(...), rte_eth_dev_start(...)
and then rte_eth_rx_burst(...)/rte_eth_tx_burst(...).
In the recovery process, user application can use same or different settings
from those before reset.
Indeed, my patch use more generic way to reset NIC.
It has only been implemented on ixgbe VF and i40e VF currently.
You can test ixgbe VF reset with testpmd as follows:
1. run testpmd with 2 ixgbe VF ports belonging to same PF in rxonly mode
2. testpmd > set verbose 1 //to observe VF working
3. testpmd > show port info all //show port number and MAC addr
4. testpmd > start
5. let all ports forwarding work for a while
6. testpmd > show port stats all
7. ifconfig name-of-PF down
8. A message is shown in testpmd to indicate PF reset
9. ifconfig name-of-PF up
10. testpmd > stop // stop forwarding to avoid crash during reset
11. testpmd > port stop all
12. testpmd > port reset all
13. testpmd > port start all //recofnig all ports {color}
14. testpmd > show port info all//get mapping of port id and MAC addr for
forwarding
15. testpmd > start // restore forwarding
16. let all ports forwarding work for a while
17. testpmd > show port stats all //confirm all port can work again
18. repeat above step 7 - 17
The codes to recover traffic using rte_eth_dev_reset(...) should like as
follows:
1. rte_eth_dev_configure(...)
2. rte_eth_rx_queue_setup(...) + rte_eth_tx_queue_setup(...)
3. rte_eth_dev_callback_register(port_id, RTE_ETH_EVENT_INTR_RESET,
eth_event_callback, cb_arg)
4. rte_eth_dev_start(...)
5. start transmitting and receiving
6. When detecting Reset event due to 'ifconfig PF down', eth_event_callback
will be called.
eth_event_callback( ) should trigger following step 7-14
7. stop transmitting and receiving
8. wait and confirm both transmitting and receiving are stopped.
9. rte_eth_dev_stop(...)
10. try rte_eth_dev_reset(...) multiple times until it return 0, and then
following step 11-14 to restart the port
11. rte_eth_dev_configure(...)
12. rte_eth_rx_queue_setup(...) + rte_eth_tx_queue_setup(...)
13. rte_eth_dev_start(...)
14. restart transmitting and receiving
All configurations including step 1/2/3/4/6/8/9/10/11/12/13 had better be run
in same thread like testpmd main thread.
In above step 10, if the PF is down, rte_eth_dev_reset(...) will fail, so it
should try multiple times until the PF is UP.
Regards
-Wei
> -Original Message-
> From: luca.bocca...@gmail.com [mailto:luca.bocca...@gmail.com]
> Sent: Tuesday, October 24, 2017 9:16 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; Dai, Wei ;
> Horton, Remy
> Subject: [PATCH 0/3] RFC: implement VF reset for i40e, e1000 and ixgbe
>
> From: Luca Boccassi
>
> These patches were originally sent by Wenzhuo Lu:
>
> http://dpdk.org/dev/patchwork/patch/14009/
> http://dpdk.org/dev/patchwork/patch/14010/
> http://dpdk.org/dev/patchwork/patch/14011/
>
> The current rte_eth_dev_reset API does not correctly reset the VF when the
> PF flaps on the host. With these patches, at least the ixgbe driver with a
> X540
> card (Linux kernel 4.9 on the host) appears to work correctly.
> The test is as simple ip link down/up on the host, and then check that traffic
> still flows through the VF in the guest.
>
> I am not an expert in these PMDs hence the RFC mark - I would like to ask for
> feedback and help from the PMD maintainers and developers.
>
> Thanks!
>
> Luca Boccassi (3):
> net/i40e: implement VF reset
> net/e1000: implement VF reset
> net/ixgbe: implement VF reset
>
> drivers/net/e1000/igb_ethdev.c| 59
> ++
> drivers/net/i40e/i40e_ethdev.h| 3 ++
> drivers/net/i40e/i40e_ethdev_vf.c | 56
> +---
> drivers/net/i40e/i40e_rxtx.c | 11 +++
> drivers/net/i40e/i40e_rxtx.h | 4 +++
> drivers/net/ixgbe/ixgbe_ethdev.c | 60
> ++-
> drivers/net/ixgbe/ixgbe_ethdev.h | 2 +-
> drivers/net/ixgbe/ixgbe_rxtx.c| 12 ++--
> 8 files changed, 192 insertions(+), 15 deletions(-)
>
> --
> 2.11.0
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
Reply for correct mail format.
> -Original Message-
> From: Dai, Wei
> Sent: Wednesday, October 11, 2017 3:07 PM
> To: Ma, Jianwei ; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Liang, Cunming
>
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
>
> I look through from web browser and not find following mail from Jianwei
> Ma Hope this can add his test result in the mail list
> to community.
>
> > -Original Message-
> > From: Ma, Jianwei
> > Sent: Tuesday, October 10, 2017 4:47 PM
> > To: Dai, Wei ; Lu, Wenzhuo
> ;
> > Ananyev, Konstantin ; Liang, Cunming
> >
> > Cc: dev@dpdk.org; sta...@dpdk.org
> > Subject: RE: [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
> >
> > Verified with l3fwd-power. It worked well with this patch plus
> > http://dpdk.org/dev/patchwork/patch/29000/ " [dpdk-dev] net/ixgbe:
> > fix Rx queue interrupt mapping in VF"
> >
> > -Original Message-
> > From: Dai, Wei
> > Sent: Tuesday, October 10, 2017 11:30
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> > ; Liang, Cunming
> > ; Ma, Jianwei
> > Cc: dev@dpdk.org; sta...@dpdk.org
> > Subject: RE: [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
> >
> > Hi, Jianwei
> > How about your test result ?
> >
> > Hi Wenzhuo
> > Would you please review this patch ?
> >
> > Thanks a lot !
> >
> > > -Original Message-
> > > From: Dai, Wei
> > > Sent: Thursday, September 28, 2017 10:29 AM
> > > To: Lu, Wenzhuo ; Ananyev, Konstantin
> > > ; Liang, Cunming
> > > ; Ma, Jianwei
> > > Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> > > Subject: [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
> > >
> > > When a VF port is bound to VFIO-PIC, only miscellaneous interrupt is
> > > mapped to VFIO vector 0 in eth_ixgbevf_dev_init( ).
> > > In ixgbevf_dev_start(), if previous VFIO interrupt mapping set in
> > > eth_ixgbevf_dev_init( ) is not cleard, it will fail when calling
> > > rte_intr_enable( ) tries to map Rx queue interrupt to other VFIO
> > > vectors. This patch clears the VFIO interrupt mappings before
> > > setting both miscellaneous and Rx queue interrupt mappings again to
> > > avoid
> > failure.
> > >
> > > Fixes: 77234603fba0 ("net/ixgbe: support VF mailbox interrupt for
> > > link
> > > up/down")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Wei Dai
Tested-by: Jianwei Ma
> > > ---
> > > drivers/net/ixgbe/ixgbe_ethdev.c | 9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > index 9ca5cbc..f49c616 100644
> > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > @@ -5046,6 +5046,15 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
> > > }
> > > ixgbevf_configure_msix(dev);
> > >
> > > + /* When a VF port is bound to VFIO-PCI, only miscellaneous
> interrupt
> > > + * is mapped to VFIO vector 0 in eth_ixgbevf_dev_init( ).
> > > + * If previous VFIO interrupt mapping setting in
> eth_ixgbevf_dev_init( )
> > > + * is not cleared, it will fail when following rte_intr_enable( ) tries
> > > + * to map Rx queue interrupt to other VFIO vectors.
> > > + * So clear uio/vfio intr/evevnfd first to avoid failure.
> > > + */
> > > + rte_intr_disable(intr_handle);
> > > +
> > > rte_intr_enable(intr_handle);
> > >
> > > /* Re-enable interrupt for VF */
> > > --
> > > 2.7.5
Re: [dpdk-dev] [PATCH] net/ixgbe: fix Rx queue interrupt mapping in VF
I look through from web browser and not find following mail from Jianwei Ma
Hope this can add his test result in the mail list to community.
> -Original Message-
> From: Ma, Jianwei
> Sent: Tuesday, October 10, 2017 4:48 PM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Ananyev, Konstantin
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: fix Rx queue interrupt mapping in VF
>
> Verified with l3fwd-power. It worked well with this patch plus
> http://dpdk.org/dev/patchwork/patch/29221/ "[dpdk-dev,v2] net/ixgbe:
> fix VFIO interrupt mapping in VF"
>
> -Original Message-
> From: Dai, Wei
> Sent: Tuesday, October 10, 2017 11:26
> To: Lu, Wenzhuo ; Ananyev, Konstantin
> ; Ma, Jianwei
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: fix Rx queue interrupt mapping in VF
>
> Hi, Jianwei
> How about your test result ?
>
> Hi, Wenzhuo
> Would you please review this patch ?
>
> Thanks a lot !
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, September 20, 2017 6:18 PM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> >
> > Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> > Subject: [PATCH] net/ixgbe: fix Rx queue interrupt mapping in VF
> >
> > When a VF port is bound to VFIO-PCI, miscellaneous interrupt is mapped
> > to MSI-X vector 0 and Rx queues interrupt are mapped to other vectors
> > in vfio_enable_msix( ). To simplify implementation, all VFIO-PCI bound
> > ixgbe VF Rx queue interrupts can be mapped in vector 1. And as current
> > igb_uio only support only one vector, ixgbe VF PMD should use vector 0
> > for igb_uio and vector 1 for VFIO-PCI. Without this patch, VF Rx queue
> > interrupt is mapped to vector 0 in register settings and mapped to
> > VFIO vector 1 in vfio_enable_msix( ), and then all Rx queue interrupts will
> be missed.
> >
> > Fixes: b13bfab4cdbe ("eal: reserve VFIO vector zero for misc
> > interrupt")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
Tested-by: Jianwei Ma
> > ---
> > drivers/net/ixgbe/ixgbe_ethdev.c | 25 ++---
> > 1 file changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 9ca5cbc..39a3d8c 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -5029,7 +5029,10 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
> >
> > /* check and configure queue intr-vector mapping */
> > if (dev->data->dev_conf.intr_conf.rxq != 0) {
> > - intr_vector = dev->data->nb_rx_queues;
> > + /* According to datasheet, only vector 0/1/2 can be used,
> > +* now only one vector is used for Rx queue
> > +*/
> > + intr_vector = 1;
> > if (rte_intr_efd_enable(intr_handle, intr_vector))
> > return -1;
> > }
> > @@ -5556,9 +5559,12 @@ ixgbevf_dev_rx_queue_intr_enable(struct
> > rte_eth_dev *dev, uint16_t queue_id)
> > uint32_t mask;
> > struct ixgbe_hw *hw =
> > IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > + uint32_t vec = IXGBE_MISC_VEC_ID;
> >
> > mask = IXGBE_READ_REG(hw, IXGBE_VTEIMS);
> > - mask |= (1 << IXGBE_MISC_VEC_ID);
> > + if (rte_intr_allow_others(intr_handle))
> > + vec = IXGBE_RX_VEC_START;
> > + mask |= (1 << vec);
> > RTE_SET_USED(queue_id);
> > IXGBE_WRITE_REG(hw, IXGBE_VTEIMS, mask);
> >
> > @@ -5573,9 +5579,14 @@ ixgbevf_dev_rx_queue_intr_disable(struct
> > rte_eth_dev *dev, uint16_t queue_id)
> > uint32_t mask;
> > struct ixgbe_hw *hw =
> > IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > + struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> > + struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
> > + uint32_t vec = IXGBE_MISC_VEC_ID;
> >
> > mask = IXGBE_READ_REG(hw, IXGBE_VTEIMS);
> > - mask &= ~(1 << IXGBE_MISC_VEC_ID);
> > + if (rte_intr_allow_others(intr_handle))
> > + vec = IXGBE_RX_VEC_START;
> > + mask &= ~(1 << vec);
> > RTE_SET_USED(queue_id);
> > IXGBE_WRITE_REG(hw, IXGBE_VTEIMS, mask);
> >
> > @@ -5717,6 +5728,7 @@ ixgbevf_configure_msix(struct rte_eth_dev
> *dev)
> > IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > uint32_t q_idx;
> > uint32_t vector
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
I look through from web browser and not find following mail from Jianwei Ma
Hope this can add his test result in the mail list to community.
> -Original Message-
> From: Ma, Jianwei
> Sent: Tuesday, October 10, 2017 4:47 PM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Ananyev, Konstantin ; Liang, Cunming
>
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
>
> Verified with l3fwd-power. It worked well with this patch plus
> http://dpdk.org/dev/patchwork/patch/29000/ " [dpdk-dev] net/ixgbe: fix
> Rx queue interrupt mapping in VF"
>
> -Original Message-
> From: Dai, Wei
> Sent: Tuesday, October 10, 2017 11:30
> To: Lu, Wenzhuo ; Ananyev, Konstantin
> ; Liang, Cunming
> ; Ma, Jianwei
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
>
> Hi, Jianwei
> How about your test result ?
>
> Hi Wenzhuo
> Would you please review this patch ?
>
> Thanks a lot !
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Thursday, September 28, 2017 10:29 AM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> > ; Liang, Cunming
> > ; Ma, Jianwei
> > Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> > Subject: [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
> >
> > When a VF port is bound to VFIO-PIC, only miscellaneous interrupt is
> > mapped to VFIO vector 0 in eth_ixgbevf_dev_init( ).
> > In ixgbevf_dev_start(), if previous VFIO interrupt mapping set in
> > eth_ixgbevf_dev_init( ) is not cleard, it will fail when calling
> > rte_intr_enable( ) tries to map Rx queue interrupt to other VFIO
> > vectors. This patch clears the VFIO interrupt mappings before setting
> > both miscellaneous and Rx queue interrupt mappings again to avoid
> failure.
> >
> > Fixes: 77234603fba0 ("net/ixgbe: support VF mailbox interrupt for link
> > up/down")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> Tested-by: Jianwei Ma
> > ---
> > drivers/net/ixgbe/ixgbe_ethdev.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 9ca5cbc..f49c616 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -5046,6 +5046,15 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
> > }
> > ixgbevf_configure_msix(dev);
> >
> > + /* When a VF port is bound to VFIO-PCI, only miscellaneous interrupt
> > +* is mapped to VFIO vector 0 in eth_ixgbevf_dev_init( ).
> > +* If previous VFIO interrupt mapping setting in eth_ixgbevf_dev_init( )
> > +* is not cleared, it will fail when following rte_intr_enable( ) tries
> > +* to map Rx queue interrupt to other VFIO vectors.
> > +* So clear uio/vfio intr/evevnfd first to avoid failure.
> > +*/
> > + rte_intr_disable(intr_handle);
> > +
> > rte_intr_enable(intr_handle);
> >
> > /* Re-enable interrupt for VF */
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
Hi, Jianwei
How about your test result ?
Hi Wenzhuo
Would you please review this patch ?
Thanks a lot !
> -Original Message-
> From: Dai, Wei
> Sent: Thursday, September 28, 2017 10:29 AM
> To: Lu, Wenzhuo ; Ananyev, Konstantin
> ; Liang, Cunming
> ; Ma, Jianwei
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: [PATCH v2] net/ixgbe: fix VFIO interrupt mapping in VF
>
> When a VF port is bound to VFIO-PIC, only miscellaneous interrupt is mapped
> to VFIO vector 0 in eth_ixgbevf_dev_init( ).
> In ixgbevf_dev_start(), if previous VFIO interrupt mapping set in
> eth_ixgbevf_dev_init( ) is not cleard, it will fail when calling
> rte_intr_enable( )
> tries to map Rx queue interrupt to other VFIO vectors. This patch clears the
> VFIO interrupt mappings before setting both miscellaneous and Rx queue
> interrupt mappings again to avoid failure.
>
> Fixes: 77234603fba0 ("net/ixgbe: support VF mailbox interrupt for link
> up/down")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 9ca5cbc..f49c616 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -5046,6 +5046,15 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
> }
> ixgbevf_configure_msix(dev);
>
> + /* When a VF port is bound to VFIO-PCI, only miscellaneous interrupt
> + * is mapped to VFIO vector 0 in eth_ixgbevf_dev_init( ).
> + * If previous VFIO interrupt mapping setting in eth_ixgbevf_dev_init( )
> + * is not cleared, it will fail when following rte_intr_enable( ) tries
> + * to map Rx queue interrupt to other VFIO vectors.
> + * So clear uio/vfio intr/evevnfd first to avoid failure.
> + */
> + rte_intr_disable(intr_handle);
> +
> rte_intr_enable(intr_handle);
>
> /* Re-enable interrupt for VF */
> --
> 2.7.5
Re: [dpdk-dev] [PATCH] net/ixgbe: fix Rx queue interrupt mapping in VF
Hi, Jianwei
How about your test result ?
Hi, Wenzhuo
Would you please review this patch ?
Thanks a lot !
> -Original Message-
> From: Dai, Wei
> Sent: Wednesday, September 20, 2017 6:18 PM
> To: Lu, Wenzhuo ; Ananyev, Konstantin
>
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: [PATCH] net/ixgbe: fix Rx queue interrupt mapping in VF
>
> When a VF port is bound to VFIO-PCI, miscellaneous interrupt is mapped to
> MSI-X vector 0 and Rx queues interrupt are mapped to other vectors in
> vfio_enable_msix( ). To simplify implementation, all VFIO-PCI bound ixgbe VF
> Rx queue interrupts can be mapped in vector 1. And as current igb_uio only
> support only one vector, ixgbe VF PMD should use vector 0 for igb_uio and
> vector 1 for VFIO-PCI. Without this patch, VF Rx queue interrupt is mapped
> to vector 0 in register settings and mapped to VFIO vector 1 in
> vfio_enable_msix( ), and then all Rx queue interrupts will be missed.
>
> Fixes: b13bfab4cdbe ("eal: reserve VFIO vector zero for misc interrupt")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 25 ++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 9ca5cbc..39a3d8c 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -5029,7 +5029,10 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
>
> /* check and configure queue intr-vector mapping */
> if (dev->data->dev_conf.intr_conf.rxq != 0) {
> - intr_vector = dev->data->nb_rx_queues;
> + /* According to datasheet, only vector 0/1/2 can be used,
> + * now only one vector is used for Rx queue
> + */
> + intr_vector = 1;
> if (rte_intr_efd_enable(intr_handle, intr_vector))
> return -1;
> }
> @@ -5556,9 +5559,12 @@ ixgbevf_dev_rx_queue_intr_enable(struct
> rte_eth_dev *dev, uint16_t queue_id)
> uint32_t mask;
> struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + uint32_t vec = IXGBE_MISC_VEC_ID;
>
> mask = IXGBE_READ_REG(hw, IXGBE_VTEIMS);
> - mask |= (1 << IXGBE_MISC_VEC_ID);
> + if (rte_intr_allow_others(intr_handle))
> + vec = IXGBE_RX_VEC_START;
> + mask |= (1 << vec);
> RTE_SET_USED(queue_id);
> IXGBE_WRITE_REG(hw, IXGBE_VTEIMS, mask);
>
> @@ -5573,9 +5579,14 @@ ixgbevf_dev_rx_queue_intr_disable(struct
> rte_eth_dev *dev, uint16_t queue_id)
> uint32_t mask;
> struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> + struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
> + uint32_t vec = IXGBE_MISC_VEC_ID;
>
> mask = IXGBE_READ_REG(hw, IXGBE_VTEIMS);
> - mask &= ~(1 << IXGBE_MISC_VEC_ID);
> + if (rte_intr_allow_others(intr_handle))
> + vec = IXGBE_RX_VEC_START;
> + mask &= ~(1 << vec);
> RTE_SET_USED(queue_id);
> IXGBE_WRITE_REG(hw, IXGBE_VTEIMS, mask);
>
> @@ -5717,6 +5728,7 @@ ixgbevf_configure_msix(struct rte_eth_dev *dev)
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> uint32_t q_idx;
> uint32_t vector_idx = IXGBE_MISC_VEC_ID;
> + uint32_t base = IXGBE_MISC_VEC_ID;
>
> /* Configure VF other cause ivar */
> ixgbevf_set_ivar_map(hw, -1, 1, vector_idx); @@ -5727,6 +5739,11
> @@ ixgbevf_configure_msix(struct rte_eth_dev *dev)
> if (!rte_intr_dp_is_en(intr_handle))
> return;
>
> + if (rte_intr_allow_others(intr_handle)) {
> + base = IXGBE_RX_VEC_START;
> + vector_idx = IXGBE_RX_VEC_START;
> + }
> +
> /* Configure all RX queues of VF */
> for (q_idx = 0; q_idx < dev->data->nb_rx_queues; q_idx++) {
> /* Force all queue use vector 0,
> @@ -5734,6 +5751,8 @@ ixgbevf_configure_msix(struct rte_eth_dev *dev)
>*/
> ixgbevf_set_ivar_map(hw, 0, q_idx, vector_idx);
> intr_handle->intr_vec[q_idx] = vector_idx;
> + if (vector_idx < base + intr_handle->nb_efd - 1)
> + vector_idx++;
> }
> }
>
> --
> 2.7.5
Re: [dpdk-dev] [PATCH v5] net/i40e: fix mirror rule reset when port is stopped
> -Original Message- > From: Ananyev, Konstantin > Sent: Saturday, September 23, 2017 6:37 PM > To: Wu, Jingjing ; Dai, Wei ; > Xing, Beilei > Cc: dev@dpdk.org; sta...@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v5] net/i40e: fix mirror rule reset when port > is stopped > > > > > -Original Message- > > From: Wu, Jingjing > > Sent: Saturday, September 23, 2017 3:27 AM > > To: Ananyev, Konstantin ; Dai, Wei > > ; Xing, Beilei > > Cc: dev@dpdk.org; sta...@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH v5] net/i40e: fix mirror rule reset > > when port is stopped > > > > > > > > > -Original Message- > > > From: Ananyev, Konstantin > > > Sent: Thursday, September 21, 2017 6:46 AM > > > To: Dai, Wei ; Wu, Jingjing > > > ; Xing, Beilei > > > Cc: dev@dpdk.org; sta...@dpdk.org > > > Subject: RE: [dpdk-dev] [PATCH v5] net/i40e: fix mirror rule reset > > > when port is stopped > > > > > > Hi Wei, > > > > > > > > > > > Hi, Konstantin > > > > > > > > Without this patch, when a port is stopped, all mirror SW resource > > > > are cleared but HW > > > settings are still there. > > > > And once the port is started again, creating mirror rule may fail > > > > due to remain HW > > > settings. > > > > > > > > There is a testpmd use case which can show why this patch is needed. > > > > 1. bind PF to igb_uio > > > > #/root/dpdk-devbind.py -b igb_uio :08:00.0 2. create 2 VFs > > > > #echo 2 > /sys/bus/pci/devices/\:08\:00.0/max_vfs > > > > 3. launch testpmd with PF, and set port mirror configuration > > > > #./x86_64-native-linuxapp-gcc/app/testpmd -c 3 -n 4 -- -i Testpmd > > > > > set port 0 mirror-rule 0 pool-mirror-up 0x1 dst-pool 1 on > > > > Testpmd > quit 4. relaunch testpmd with PF, and set port mirror as > > > > the same configuration #./x86_64-native-linuxapp-gcc/app/testpmd > > > > -c 3 -n 4 -- -i Testpmd > set port 0 mirror-rule 0 pool-mirror-up > > > > 0x1 dst-pool 1 on I40e_mirror_rule_set( ): failed to add mirror > > > > rule: ret = -53, aq_err = 13. > > > > Mirror rule add error: (Function not implemented) > > > > > > > > When testpmd is quitted, rte_eth_dev_stop( ) and then > rte_eth_dev_close( ) are called. > > > > In these function, i40e_dev_stop( ) and i40e_dev_close( ) is called. > > > > And i40e_dev_stop is also called by i40e_dev_close( ). > > > > > > > > Without this patch, the error in second running of testpmd always > happen. > > > > This patch can address this error. > > > > > > Thanks for explanation. > > > Though it seems that the patch while fixing the issue might > > > introduce some > > > inconsistences: > > > 1. right now for i40e: dev_stop(port); dev_start(port) would keep > > > existing HW mirror rule working. > > >With your patch is not any more. > > > 2. What about ixgbe? Do we also need to change its behavior? > > > As I can see right now ixgbe doesn't reset any mirror rules at > dev_stop(). > > >Would it be reset automatically, or do we need to update ixgbe PMD > too? > > > > > > About #1 - if we'll decide that this is a desired behavior that > > > dev_stop() voids all mirror rules, then at least we probably need to > update the documentation. > > > As alternative - at dev_stop() we can reset only actual HW rule, but > > > keep SW configuration intact, and restore them at dev_start(). > > > I personally think second option is a bit better - as it preserves > > > existing behavior, and probably more convenient for the user. > > > > Yes, you reminded me the mirror is to VF. The mirror rule should be > > kept or at least be restored when device start again.. > > Because the dev_stop should only stop the pf interface, but not affect > > VF. It looks like we don't delete the VEB we dev_stop. > > The reset behavior may need to be done in dev_close, but not in dev_stop. > > if we can move that code into dev_close() , then indeed might be a better > approach. > > > > > > > > > About the patch itself, why just not: > > > while ((p_mirror = TAILQ_FIRST(&pf->mirror_list))) > > > i40e_mirror_rule_reset(dev, p_mirror->index); > > > > > Wei's v1 patch is doing like that. But I commented it to change it. > > Because i40e_mirror_rule_reset is doing a search in the list which is not > necessary. > > Yes, but it is a control path, so need to be extra quick here. > As a plus - avoid code duplication and easier to control/maintain it. > Konstantin > Thanks to Konstantin and Jingjing for all of your suggestion. I will work out v6 patch to put all these mirror reset operations in dev_close( ). As to ixgbe, same scheme will be tried and tested.
Re: [dpdk-dev] [PATCH v5] net/i40e: fix mirror rule reset when port is stopped
Hi, Konstantin
Without this patch, when a port is stopped, all mirror SW resource are cleared
but HW settings are still there.
And once the port is started again, creating mirror rule may fail due to remain
HW settings.
There is a testpmd use case which can show why this patch is needed.
1. bind PF to igb_uio
#/root/dpdk-devbind.py -b igb_uio :08:00.0
2. create 2 VFs
#echo 2 > /sys/bus/pci/devices/\:08\:00.0/max_vfs
3. launch testpmd with PF, and set port mirror configuration
#./x86_64-native-linuxapp-gcc/app/testpmd -c 3 -n 4 -- -i
Testpmd > set port 0 mirror-rule 0 pool-mirror-up 0x1 dst-pool 1 on
Testpmd > quit
4. relaunch testpmd with PF, and set port mirror as the same configuration
#./x86_64-native-linuxapp-gcc/app/testpmd -c 3 -n 4 -- -i
Testpmd > set port 0 mirror-rule 0 pool-mirror-up 0x1 dst-pool 1 on
I40e_mirror_rule_set( ): failed to add mirror rule: ret = -53, aq_err = 13.
Mirror rule add error: (Function not implemented)
When testpmd is quitted, rte_eth_dev_stop( ) and then rte_eth_dev_close( ) are
called.
In these function, i40e_dev_stop( ) and i40e_dev_close( ) is called.
And i40e_dev_stop is also called by i40e_dev_close( ).
Without this patch, the error in second running of testpmd always happen.
This patch can address this error.
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Wednesday, September 20, 2017 5:23 PM
> To: Dai, Wei ; Wu, Jingjing ;
> Xing, Beilei
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v5] net/i40e: fix mirror rule reset when port
> is stopped
>
> Hi Wei,
>
> >
> > When an i40e PF port is stopped, all mirror rules should be removed.
> > All rule related software and hardware resources should also be
> > removed.
>
> Could you clarify why we have to remove all mirror rules when PF is
> stopped?
> As I remember mirror rule can direct to VF, which still can be running, no?
> Konstantin
>
> >
> > Fixes: a4def5edf0fc ("i40e: enable port mirroring")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > Tested-by: Lijuan Tu
> > ---
> > drivers/net/i40e/i40e_ethdev.c | 21 -
> > 1 file changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index f12aefa..14cf6c0 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -361,6 +361,12 @@ static int i40e_dev_sync_phy_type(struct
> i40e_hw
> > *hw); static void i40e_configure_registers(struct i40e_hw *hw);
> > static void i40e_hw_init(struct rte_eth_dev *dev); static int
> > i40e_config_qinq(struct i40e_hw *hw, struct i40e_vsi *vsi);
> > +static enum i40e_status_code i40e_aq_del_mirror_rule(struct i40e_hw
> *hw,
> > +uint16_t seid,
> > +uint16_t rule_type,
> > +uint16_t *entries,
> > +uint16_t count,
> > +uint16_t rule_id);
> > static int i40e_mirror_rule_set(struct rte_eth_dev *dev,
> > struct rte_eth_mirror_conf *mirror_conf,
> > uint8_t sw_id, uint8_t on);
> > @@ -2069,6 +2075,7 @@ i40e_dev_stop(struct rte_eth_dev *dev)
> > struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> > struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
> > int i;
> > + int ret;
> >
> > if (hw->adapter_stopped == 1)
> > return;
> > @@ -2096,10 +2103,22 @@ i40e_dev_stop(struct rte_eth_dev *dev)
> >
> > /* Remove all mirror rules */
> > while ((p_mirror = TAILQ_FIRST(&pf->mirror_list))) {
> > + ret = i40e_aq_del_mirror_rule(hw,
> > + pf->main_vsi->veb->seid,
> > + p_mirror->rule_type,
> > + p_mirror->entries,
> > + p_mirror->num_entries,
> > + p_mirror->id);
> > + if (ret < 0)
> > + PMD_DRV_LOG(ERR, "failed to remove mirror rule: "
> > + "status = %d, aq_err = %d.", ret,
> > + hw->aq.asq_last_status);
> > +
> > + /* remove mirror software resource any way */
> > TAILQ_REMOVE(&pf->mirror_list, p_mirror, rules);
> > rte_free(p_mirror);
> > + pf->nb_mirror_rule--;
> > }
> > - pf->nb_mirror_rule = 0;
> >
> > if (!rte_intr_allow_others(intr_handle))
> > /* resume to the default handler */
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v2] net/i40e: fix mirror rule reset when port is stopped
Many thanks to Jingjing and Beilei.
Sorry, this patch is a wrong v2 due to a building error.
I have submitted another v2 .
Anyway, I will submit v3 patch per your feedback.
> -Original Message-
> From: Wu, Jingjing
> Sent: Tuesday, September 19, 2017 10:21 AM
> To: Xing, Beilei ; Dai, Wei
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2] net/i40e: fix mirror rule reset when port
> is stopped
>
>
>
> > -Original Message-
> > From: Xing, Beilei
> > Sent: Monday, September 11, 2017 10:46 AM
> > To: Dai, Wei ; Wu, Jingjing
> > Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH v2] net/i40e: fix mirror rule reset
> > when port is stopped
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > > Sent: Monday, September 11, 2017 10:12 AM
> > > To: Wu, Jingjing ; Xing, Beilei
> > >
> > > Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> > > Subject: [dpdk-dev] [PATCH v2] net/i40e: fix mirror rule reset when
> > > port is stopped
> > >
> > > When an i40e PF port is stopped, all mirror rules should be removed.
> > > All rule related software and hardware resources should also be
> removed.
> > >
> > > Fixes: a4def5edf0fc ("i40e: enable port mirroring")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Wei Dai
> > > Tested-by: Lijuan Tu
> > > ---
> > > drivers/net/i40e/i40e_ethdev.c | 18 +++---
> > > 1 file changed, 15 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > > b/drivers/net/i40e/i40e_ethdev.c index 5f26e24..a278748 100644
> > > --- a/drivers/net/i40e/i40e_ethdev.c
> > > +++ b/drivers/net/i40e/i40e_ethdev.c
> > > @@ -2094,10 +2094,22 @@ i40e_dev_stop(struct rte_eth_dev *dev)
> > >
> > > /* Remove all mirror rules */
> > > while ((p_mirror = TAILQ_FIRST(&pf->mirror_list))) {
> > > - TAILQ_REMOVE(&pf->mirror_list, p_mirror, rules);
> > > - rte_free(p_mirror);
> > > + int ret;
>
> You can move the declaration of ret to the beginning of the func.
>
> > > + ret = i40e_aq_del_mirror_rule(hw, pf->main_vsi->veb->seid,
> > > + p_mirror->rule_type,
> > > + p_mirror->entries,
> > > + p_mirror->num_entries,
> > > + p_mirror->id);
> > > + if (ret < 0) {
> > > + PMD_DRV_LOG(ERR, "failed to remove mirror rule: "
> > > + "status = %d, aq_err = %d.", ret,
> > > + hw->aq.asq_last_status);
> > > + } else {
> > > + TAILQ_REMOVE(&pf->mirror_list, p_mirror, rules);
> > > + rte_free(p_mirror);
> > > + pf->nb_mirror_rule--;
> > > + }
> >
> > little comment: else statement can be omitted here.
>
> Same comment, software entries need to be released.
>
> Thanks
> Jingjing
Re: [dpdk-dev] [PATCH v9 0/5] Support of NIC reset and keep same port id
Hi, Thomas Thanks for your great support ! > -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Thursday, September 14, 2017 5:02 AM > To: Dai, Wei > Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, > Konstantin ; Wu, Jingjing > ; Xing, Beilei > Subject: Re: [dpdk-dev] [PATCH v9 0/5] Support of NIC reset and keep same > port id > > > Wei Dai (5): > > ethdev: add support of NIC reset > > net/ixgbe: add support of reset > > net/i40e: add support of reset > > app/testpmd: enhance command to test NIC reset > > doc: add description of the NIC reset API > > Sorry for being so late to get back to it. > > Applied, thanks for the improvements done in latest versions.
Re: [dpdk-dev] [PATCH] net/i40e: fix mirror rule reset when port is stopped
> -Original Message-
> From: Wu, Jingjing
> Sent: Thursday, September 7, 2017 3:51 PM
> To: Dai, Wei ; Xing, Beilei
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH] net/i40e: fix mirror rule reset when port is stopped
>
>
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, September 6, 2017 10:52 PM
> > To: Wu, Jingjing ; Xing, Beilei
> >
> > Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> > Subject: [PATCH] net/i40e: fix mirror rule reset when port is stopped
> >
> > When an i40e PF port is stopped, all mirror rules should be removed.
> > All rule related SW and HW resources should also be removed. All of
> > them are should be removed by calling i40e_mirror_rule_reset( ).
> >
> > Fixes: a4def5edf0fc ("i40e: enable port mirroring")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/i40e/i40e_ethdev.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 5f26e24..93fb6cd 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -2094,8 +2094,7 @@ i40e_dev_stop(struct rte_eth_dev *dev)
> >
> > /* Remove all mirror rules */
> > while ((p_mirror = TAILQ_FIRST(&pf->mirror_list))) {
> > - TAILQ_REMOVE(&pf->mirror_list, p_mirror, rules);
> > - rte_free(p_mirror);
> > + i40e_mirror_rule_reset(dev, p_mirror->index);
> > }
> > pf->nb_mirror_rule = 0;
> >
> It is correct to remove mirror rule in HW. But looking into the function
> i40e_mirror_rul_reset, it's waste to call the function here.
> It is much economic to do like
> while ((p_mirror = TAILQ_FIRST(&pf->mirror_list))) {
> i40e_aq_del_mirror_rule(hw, seid,
> p_mirror->rule_type,
> p_mirror->entries,
> p_mirror->num_entries, p_mirror->id);
> TAILQ_REMOVE(&pf->mirror_list, p_mirror, rules);
> rte_free(p_mirror);
> i40e_mirror_rule_reset(dev, p_mirror->index);
Indeed, the function i40e_mirror_rule_reset( ) includes above 3 code lines:
I40e_aq_del_mirror_rule( ), TAILQ_REMOVE( ) and rte_free( ).
So did you suggest that use these 3 lines instead of calling
i40e_mirror_rule_reset( ) ?
I mean i40e_mirror_rule_reset( ) is not necessary in your suggestion.
What's more, all these are in i40e_dev_stop( ), so it doesn't matter which
method
to get same result :-)
> }
>
> Thanks
> Jingjing
Re: [dpdk-dev] [PATCH] net/i40e: fix mirror rule reset when port is stopped
Hi, Lijuan
How about your test result ?
> -Original Message-
> From: Dai, Wei
> Sent: Wednesday, September 6, 2017 10:52 PM
> To: Wu, Jingjing ; Xing, Beilei
>
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: [PATCH] net/i40e: fix mirror rule reset when port is stopped
>
> When an i40e PF port is stopped, all mirror rules should be removed.
> All rule related SW and HW resources should also be removed. All of them
> are should be removed by calling i40e_mirror_rule_reset( ).
>
> Fixes: a4def5edf0fc ("i40e: enable port mirroring")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> drivers/net/i40e/i40e_ethdev.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 5f26e24..93fb6cd 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -2094,8 +2094,7 @@ i40e_dev_stop(struct rte_eth_dev *dev)
>
> /* Remove all mirror rules */
> while ((p_mirror = TAILQ_FIRST(&pf->mirror_list))) {
> - TAILQ_REMOVE(&pf->mirror_list, p_mirror, rules);
> - rte_free(p_mirror);
> + i40e_mirror_rule_reset(dev, p_mirror->index);
> }
> pf->nb_mirror_rule = 0;
>
> --
> 2.7.5
Re: [dpdk-dev] [PATCH] net/i40e: fix mirror rule reset when port is stopped
> -Original Message-
> From: Dai, Wei
> Sent: Wednesday, September 6, 2017 10:52 PM
> To: Wu, Jingjing ; Xing, Beilei
>
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: [PATCH] net/i40e: fix mirror rule reset when port is stopped
>
> When an i40e PF port is stopped, all mirror rules should be removed.
> All rule related SW and HW resources should also be removed. All of them
> are should be removed by calling i40e_mirror_rule_reset( ).
>
> Fixes: a4def5edf0fc ("i40e: enable port mirroring")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> drivers/net/i40e/i40e_ethdev.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 5f26e24..93fb6cd 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -2094,8 +2094,7 @@ i40e_dev_stop(struct rte_eth_dev *dev)
>
> /* Remove all mirror rules */
> while ((p_mirror = TAILQ_FIRST(&pf->mirror_list))) {
> - TAILQ_REMOVE(&pf->mirror_list, p_mirror, rules);
> - rte_free(p_mirror);
> + i40e_mirror_rule_reset(dev, p_mirror->index);
> }
> pf->nb_mirror_rule = 0;
>
> --
> 2.7.5
Re: [dpdk-dev] [PATCH v4] net/ixgbe: add support of 2.5G and 5G on X550
> -Original Message- > From: Lu, Wenzhuo > Sent: Thursday, July 27, 2017 12:59 AM > To: Dai, Wei ; Ananyev, Konstantin > > Cc: dev@dpdk.org > Subject: RE: [PATCH v4] net/ixgbe: add support of 2.5G and 5G on X550 > > Hi Wei, > > > -----Original Message- > > From: Dai, Wei > > Sent: Wednesday, July 26, 2017 11:30 AM > > To: Lu, Wenzhuo ; Ananyev, Konstantin > > > > Cc: dev@dpdk.org; Dai, Wei > > Subject: [PATCH v4] net/ixgbe: add support of 2.5G and 5G on X550 > > > > This patch adds support of 2.5G and 5G ethernet interface on X550. > > > > Signed-off-by: Wei Dai > > --- > > drivers/net/ixgbe/base/ixgbe_type.h | 5 + > > drivers/net/ixgbe/ixgbe_ethdev.c| 27 > --- > > 2 files changed, 29 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/net/ixgbe/base/ixgbe_type.h > > b/drivers/net/ixgbe/base/ixgbe_type.h > > index bda8558..3fd5425 100644 > > --- a/drivers/net/ixgbe/base/ixgbe_type.h > > +++ b/drivers/net/ixgbe/base/ixgbe_type.h > > @@ -3408,6 +3408,11 @@ typedef u32 ixgbe_link_speed; #define > > IXGBE_LINK_SPEED_82599_AUTONEG > > (IXGBE_LINK_SPEED_100_FULL | \ > > IXGBE_LINK_SPEED_1GB_FULL | \ > > IXGBE_LINK_SPEED_10GB_FULL) > > +#define IXGBE_LINK_SPEED_X550_AUTONEG > > (IXGBE_LINK_SPEED_100_FULL | \ > > + IXGBE_LINK_SPEED_1GB_FULL | \ > > + IXGBE_LINK_SPEED_2_5GB_FULL | \ > > + IXGBE_LINK_SPEED_5GB_FULL | \ > > + IXGBE_LINK_SPEED_10GB_FULL) > Just noticed you changed base code. As we discussed before, I don't mean > that. Actually, I suggest to put it in, for example, ixgbe_ethdev.h Yes, you are right. Your method is better. I will follow it in my v5 patch.
Re: [dpdk-dev] [PATCH v3] net/ixgbe: add support of 2.5G and 5G on X550
> -Original Message-
> From: Lu, Wenzhuo
> Sent: Wednesday, July 26, 2017 11:02 PM
> To: Dai, Wei ; Ananyev, Konstantin
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v3] net/ixgbe: add support of 2.5G and 5G on X550
>
> Hi Wei,
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, July 26, 2017 10:43 AM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> >
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v3] net/ixgbe: add support of 2.5G and 5G on X550
> >
> > This patch adds support of 2.5G and 5G ethernet interface on X550.
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/ixgbe/base/ixgbe_type.h | 5 +
> > drivers/net/ixgbe/ixgbe_ethdev.c| 24
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/net/ixgbe/base/ixgbe_type.h
> > b/drivers/net/ixgbe/base/ixgbe_type.h
> > index bda8558..3fd5425 100644
> > --- a/drivers/net/ixgbe/base/ixgbe_type.h
> > +++ b/drivers/net/ixgbe/base/ixgbe_type.h
> > @@ -3408,6 +3408,11 @@ typedef u32 ixgbe_link_speed; #define
> > IXGBE_LINK_SPEED_82599_AUTONEG
> > (IXGBE_LINK_SPEED_100_FULL | \
> > IXGBE_LINK_SPEED_1GB_FULL | \
> > IXGBE_LINK_SPEED_10GB_FULL)
> > +#define IXGBE_LINK_SPEED_X550_AUTONEG
> > (IXGBE_LINK_SPEED_100_FULL | \
> > + IXGBE_LINK_SPEED_1GB_FULL | \
> > + IXGBE_LINK_SPEED_2_5GB_FULL | \
> > + IXGBE_LINK_SPEED_5GB_FULL | \
> > + IXGBE_LINK_SPEED_10GB_FULL)
> >
> > /* Physical layer type */
> > typedef u64 ixgbe_physical_layer;
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 194058f..bafe7f4 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -2650,6 +2650,22 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
> > speed = (hw->mac.type != ixgbe_mac_82598EB) ?
> > IXGBE_LINK_SPEED_82599_AUTONEG :
> > IXGBE_LINK_SPEED_82598_AUTONEG;
> A little confused here. I saw you erased these 3 lines of code in the previous
> version. Suppose it's better to remove them, right?
Sorry, I forgot to remove them.
I will rework on v4 patch.
Thanks
>
> > + switch (hw->mac.type) {
> > + case ixgbe_mac_82598EB:
> > + speed = IXGBE_LINK_SPEED_82598_AUTONEG;
> > + break;
> > + case ixgbe_mac_82599EB:
> > + case ixgbe_mac_X540:
> > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > + break;
> > + case ixgbe_mac_X550:
> > + case ixgbe_mac_X550EM_x:
> > + case ixgbe_mac_X550EM_a:
> > + speed = IXGBE_LINK_SPEED_X550_AUTONEG;
> > + break;
> > + default:
> > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > + }
> > } else {
> > if (*link_speeds & ETH_LINK_SPEED_10G)
> > speed |= IXGBE_LINK_SPEED_10GB_FULL; @@ -
> > 3972,6 +3988,14 @@ ixgbe_dev_link_update_share(struct rte_eth_dev
> *dev,
> > link.link_speed = ETH_SPEED_NUM_1G;
> > break;
> >
> > + case IXGBE_LINK_SPEED_2_5GB_FULL:
> > + link.link_speed = ETH_SPEED_NUM_2_5G;
> > + break;
> > +
> > + case IXGBE_LINK_SPEED_5GB_FULL:
> > + link.link_speed = ETH_SPEED_NUM_5G;
> > + break;
> > +
> > case IXGBE_LINK_SPEED_10GB_FULL:
> > link.link_speed = ETH_SPEED_NUM_10G;
> > break;
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v2] net/ixgbe: add support of 2.5G and 5G on X550
> -Original Message-
> From: Lu, Wenzhuo
> Sent: Wednesday, July 26, 2017 10:14 PM
> To: Dai, Wei ; Ananyev, Konstantin
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v2] net/ixgbe: add support of 2.5G and 5G on X550
>
> Hi Wei,
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, July 26, 2017 10:10 AM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> >
> > Cc: dev@dpdk.org
> > Subject: RE: [PATCH v2] net/ixgbe: add support of 2.5G and 5G on X550
> >
> > Hi, Wenzhuo
> > > > speed = 0x0;
> > > > if (*link_speeds == ETH_LINK_SPEED_AUTONEG) {
> > > > - speed = (hw->mac.type != ixgbe_mac_82598EB) ?
> > > > - IXGBE_LINK_SPEED_82599_AUTONEG :
> > > > - IXGBE_LINK_SPEED_82598_AUTONEG;
> > > > + switch (hw->mac.type) {
> > > > + case ixgbe_mac_82598EB:
> > > > + speed = IXGBE_LINK_SPEED_82598_AUTONEG;
> > > > + break;
> > > > +
> > > > + case ixgbe_mac_82599EB:
> > > > + case ixgbe_mac_X540:
> > > > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > > > + break;
> > > > +
> > > > + case ixgbe_mac_X550:
> > > > + case ixgbe_mac_X550EM_x:
> > > > + case ixgbe_mac_X550EM_a:
> > > > + speed = IXGBE_LINK_SPEED_100_FULL |
> > > > + IXGBE_LINK_SPEED_1GB_FULL |
> > > > + IXGBE_LINK_SPEED_10GB_FULL |
> > > > + IXGBE_LINK_SPEED_2_5GB_FULL |
> > > > + IXGBE_LINK_SPEED_5GB_FULL;
> > > Thanks for the patch. It looks good to me. A suggestion, why not
> > > define a macro like IXGBE_LINK_SPEED_82599_AUTONEG for x550?
> >
> > IXGBE_LINK_SPEED_82599_AUTONEG is defined in
> > drivers/net/ixgbe/base/ixgbe_type.h .
> > Normally, the base driver code in this file is provided and maintained
> > by another team.
> > I will ask them to add similar macro in it.
> > Currently, I'd like do this way. And I will replace it till a similar
> > macro is introduced.
> No. I'm talking about changing the base code. You can add a macro in any .h
> or even .c file you like.
> Then when there's a macro in base code, it's easier to replace a macro by
> another macro.
I'll follow your guidance in my v3 patch.
>
> >
> > >
> > > > + break;
> > > > + default:
> > > > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > > > + }
> > > > } else {
> > > > if (*link_speeds & ETH_LINK_SPEED_10G)
> > > > speed |= IXGBE_LINK_SPEED_10GB_FULL; @@ -
> > > > 3972,6 +3991,14 @@ ixgbe_dev_link_update_share(struct rte_eth_dev
> > > *dev,
> > > > link.link_speed = ETH_SPEED_NUM_1G;
> > > > break;
> > > >
> > > > + case IXGBE_LINK_SPEED_2_5GB_FULL:
> > > > + link.link_speed = ETH_SPEED_NUM_2_5G;
> > > > + break;
> > > > +
> > > > + case IXGBE_LINK_SPEED_5GB_FULL:
> > > > + link.link_speed = ETH_SPEED_NUM_5G;
> > > > + break;
> > > > +
> > > > case IXGBE_LINK_SPEED_10GB_FULL:
> > > > link.link_speed = ETH_SPEED_NUM_10G;
> > > > break;
> > > > --
> > > > 2.7.5
Re: [dpdk-dev] [PATCH v2] net/ixgbe: add support of 2.5G and 5G on X550
Hi, Wenzhuo
> > speed = 0x0;
> > if (*link_speeds == ETH_LINK_SPEED_AUTONEG) {
> > - speed = (hw->mac.type != ixgbe_mac_82598EB) ?
> > - IXGBE_LINK_SPEED_82599_AUTONEG :
> > - IXGBE_LINK_SPEED_82598_AUTONEG;
> > + switch (hw->mac.type) {
> > + case ixgbe_mac_82598EB:
> > + speed = IXGBE_LINK_SPEED_82598_AUTONEG;
> > + break;
> > +
> > + case ixgbe_mac_82599EB:
> > + case ixgbe_mac_X540:
> > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > + break;
> > +
> > + case ixgbe_mac_X550:
> > + case ixgbe_mac_X550EM_x:
> > + case ixgbe_mac_X550EM_a:
> > + speed = IXGBE_LINK_SPEED_100_FULL |
> > + IXGBE_LINK_SPEED_1GB_FULL |
> > + IXGBE_LINK_SPEED_10GB_FULL |
> > + IXGBE_LINK_SPEED_2_5GB_FULL |
> > + IXGBE_LINK_SPEED_5GB_FULL;
> Thanks for the patch. It looks good to me. A suggestion, why not define a
> macro like IXGBE_LINK_SPEED_82599_AUTONEG for x550?
IXGBE_LINK_SPEED_82599_AUTONEG is defined in
drivers/net/ixgbe/base/ixgbe_type.h .
Normally, the base driver code in this file is provided and maintained by
another team.
I will ask them to add similar macro in it.
Currently, I'd like do this way. And I will replace it till a similar macro is
introduced.
>
> > + break;
> > + default:
> > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > + }
> > } else {
> > if (*link_speeds & ETH_LINK_SPEED_10G)
> > speed |= IXGBE_LINK_SPEED_10GB_FULL; @@ -
> > 3972,6 +3991,14 @@ ixgbe_dev_link_update_share(struct rte_eth_dev
> *dev,
> > link.link_speed = ETH_SPEED_NUM_1G;
> > break;
> >
> > + case IXGBE_LINK_SPEED_2_5GB_FULL:
> > + link.link_speed = ETH_SPEED_NUM_2_5G;
> > + break;
> > +
> > + case IXGBE_LINK_SPEED_5GB_FULL:
> > + link.link_speed = ETH_SPEED_NUM_5G;
> > + break;
> > +
> > case IXGBE_LINK_SPEED_10GB_FULL:
> > link.link_speed = ETH_SPEED_NUM_10G;
> > break;
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v8 1/5] ethdev: add support of NIC reset
Many thanks, Remy. My v9 patch set has followed your guidance. > -Original Message- > From: Horton, Remy > Sent: Thursday, July 20, 2017 9:22 PM > To: Dai, Wei ; dev@dpdk.org > Cc: tho...@monjalon.net; Lu, Wenzhuo ; > Ananyev, Konstantin ; Xing, Beilei > ; Wu, Jingjing ; Mcnamara, > John > Subject: Re: [dpdk-dev] [PATCH v8 1/5] ethdev: add support of NIC reset > > See suggested wording inline > > On 17/07/2017 16:14, Wei Dai wrote: > > This patch adds a new eth_dev layer API function rte_eth_dev_reset(). > > A DPDK application can call this function to reset a NIC and keep > > its port id afterwards. > > It means that all SW resources allocated in ethdev layer should be > > kept and SW and HW resources of the NIC in PMD need to be reset in > > similar way that it runs PCI dev_uninit() and then dev_init(). > > The sequence of dev_uninit() and dev_init() can be packed into a > > single interface API rte_eth_dev_reset(). > > Please See the comments before the declaration of rte_eht_dev_reset() > > in lib/librte_ether/rte_ethdev.h to get more details on why this > > function is needed, what it does, when it should be called > > and what an application should do after calling this function. > > This patch adds a new eth_dev layer API function rte_eth_dev_reset(), > which a DPDK application can call to reset a NIC and keep its port id > afterwards. It means that all software resources allocated in the ethdev > layer are kept, and software & hardware resources of the NIC within the > NIC's PMD are reset to a state simular to that obtained by calling the > PCI dev_uninit() and then dev_init(). This effective sequence of > dev_uninit() and dev_init() is packed into a single API function > rte_eth_dev_reset(). > > Please see the comments before the declaration of rte_eht_dev_reset() > in lib/librte_ether/rte_ethdev.h to get more details on why this > function is needed, what it does, when it should be called > and what an application should do after calling this function. > > > > Signed-off-by: Wei Dai > > --- > > lib/librte_ether/rte_ethdev.c | 17 + > > lib/librte_ether/rte_ethdev.h | 33 > + > > lib/librte_ether/rte_ether_version.map | 1 + > > 3 files changed, 51 insertions(+) > > Reviewed-by: Remy Horton > > > > > /** > > + * Reset a Ethernet device and keep its port id. > > + * > > + * When a port has to be reset passively, the DPDK application can invoke > this > > + * function. For example a PF is reset, all its VFs should also be reset. > > + * Normally, a DPDK application can invoke this function when > > + * RTE_ETH_EVENT_INTR_RESET event is detected. A DPDK application > can also call > > + * this function to start an initiative port reset. > > When a port has to be reset passively, the DPDK application can invoke > this function. For example when a PF is reset, all its VFs should also > be reset. Normally a DPDK application can invoke this function when > RTE_ETH_EVENT_INTR_RESET event is detected, but can also use it to start > a port reset in other circumstances. > > > + * When this function is called, it first stops the port and then call PMD > > + * specific dev_uninit( ) and dev_init( ) to makes the port return to > > initial > > + * status in which no any Tx queue and no Rx queue are setup and the port > has > > + * just be reset and not started. And the port keeps its port id after > > calling > > + * this function. > > When this function is called, it first stops the port and then calls the > PMD specific dev_uninit( ) and dev_init( ) to return the port to initial > state, in which no Tx and Rx queues are setup, as if the port has been > reset and not started. The port keeps the port id it had before the > function call. > > > + * After calling rte_eth_dev_reset( ), the application should go through > > + * rte_eth_dev_configure( ), rte_eth_rx_queue_setup( ), > > + * rte_eth_tx_queue_setup( ) and rte_eth_dev_start( ) again to restore > > + * its previous settings or to reconfigure itself with different settings. > > After calling rte_eth_dev_reset( ), the application should use > rte_eth_dev_configure( ), rte_eth_rx_queue_setup( ), > rte_eth_tx_queue_setup( ), and rte_eth_dev_start( ) > to reconfigure the device as appropriate. > > > > + * Note: to avoid unexpected behaviour, the application should stop > calling Rx > > + * and Rx function before calling rte_eth_dev_reset( ).For thread > safety, > > + * all these controlling operations had better be made in same > thread. > > Note: To avoid unexpected behavior, the application should stop calling > Tx and Rx functions before calling rte_eth_dev_reset( ). For thread > safety, all these controlling functions should be called from the same > thread. >
Re: [dpdk-dev] [PATCH v7 0/5] Support NIC reset and keep same port id
Remy is a Native English speaker. He will help me review my v8 patch set. Thank you, Remy. > -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Monday, July 17, 2017 3:26 AM > To: Dai, Wei > Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, > Konstantin ; Wu, Jingjing > ; Xing, Beilei ; Mcnamara, > John > Subject: Re: [dpdk-dev] [PATCH v7 0/5] Support NIC reset and keep same > port id > > 13/07/2017 17:53, Wei Dai: > > chagnes: > > v7: > > add description of NIC reset in doc/poll_mode_drv.rst > > Thanks for bringing more explanations. > The texts have to be reviewed by a native english speaker. > > About the organization of the doc, it is good to explain the VF use case in > the > prog guide as you do. But you should not add it to the doxygen. > The doxygen must be concise enough and explains only the API: > - when it can be called > - what a driver is doing when calling reset > - what is the expected state of the device after reset
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix Rx/Tx queue interrupt for x550 devices
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qiming Yang
> Sent: Tuesday, July 18, 2017 10:29 AM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Lu, Wenzhuo ; Yang, Qiming
>
> Subject: [dpdk-dev] [PATCH v2] net/ixgbe: fix Rx/Tx queue interrupt for x550
> devices
>
> x550 devices not do interrupt vector mapping before enable Rx/Tx queue
> interrupt, makes interrupt mode can't work neither with igb_uio or VFIO.
>
> Fixes: d2e72774e58c ("ixgbe/base: support X550")
>
> Signed-off-by: Qiming Yang
Have looked through datasheet of 82599, X540 and X550.
Acked-by: Wei Dai
> ---
> v2 changes:
> * fixed other cause interrupt vector map and typo issue
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 9b06ac1..0caafd5 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -5611,7 +5611,8 @@ ixgbe_set_ivar_map(struct ixgbe_hw *hw, int8_t
> direction,
> tmp |= (msix_vector << (8 * (queue & 0x3)));
> IXGBE_WRITE_REG(hw, IXGBE_IVAR(idx), tmp);
> } else if ((hw->mac.type == ixgbe_mac_82599EB) ||
> - (hw->mac.type == ixgbe_mac_X540)) {
> + (hw->mac.type == ixgbe_mac_X540) ||
> + (hw->mac.type == ixgbe_mac_X550)) {
> if (direction == -1) {
> /* other causes */
> idx = ((queue & 1) * 8);
> @@ -5719,6 +5720,7 @@ ixgbe_configure_msix(struct rte_eth_dev *dev)
> break;
> case ixgbe_mac_82599EB:
> case ixgbe_mac_X540:
> + case ixgbe_mac_X550:
> ixgbe_set_ivar_map(hw, -1, 1, IXGBE_MISC_VEC_ID);
> break;
> default:
> --
> 2.7.4
Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
HI, Srini Sorry for late response. As I have pointed out that Ixgbe_reset_hw_82599( ) calls hw->phy.ops.init(hw) unconditionally, I think it is no need to call hw->phy.ops.init(hw) after ixgbe_pf_reset_hw(hw) at least for 82599. I also think that only moving "hw->phy.type = ixgbe_phy_unknown" just before ixgbe_pf_reset_hw(hw) is OK. What's more, how about X540 and X550 ? I have just got a X540 and a X550 NIC with copper interface, so I only can plug in/out the RJ45 line to help test it. Is your patch designed for plugging out original SFP and then plugging in another different type of SFP ? By the way, I'd like you provide more details on how to test your patch? With testpmd ? Or other app ? Thanks -Wei > -Original Message- > From: Yigit, Ferruh > Sent: Thursday, June 29, 2017 9:00 PM > To: Srinivasan J ; Dai, Wei > Cc: Thomas Monjalon ; dev@dpdk.org; Lu, > Wenzhuo ; Ananyev, Konstantin > > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot > swapped SFP/SFP+ > > On 5/19/2017 11:04 AM, Srinivasan J wrote: > > Hi Wei, > > Yes the changes are in ixgbe_dev_start( ), the patch shows > > the function as eth_ixgbevf_pci_remove() probably due to the way diff > > recognizes the change. I have tested the change using Intel > > Corporation 82599ES. > > Hi Srinivasan, Wei, > > What is the latest status of the patch? Are all issues pointed by Wie > addressed in the patch, or are we waiting for a new version? > > Thanks, > ferruh > > > > > Thanks, > > Srini > > > > On Tue, May 16, 2017 at 9:04 AM, Dai, Wei wrote: > >> Hi, Srini > >> > >> There is a bit confusion. Your patch shows that your code is added into > the function eth_ixgbevf_pci_remove( ). > >> But it is not. It is added into the fucntion ixgbe_dev_start( ), right ? > >> So would you please rebase it to R 17.05 ? > >> > >> Which type of ixgbe device id did you tested ? > >> > >> There are many MAC types with different device id. > >> > >> The function ixgbe_pf_reset_hw(hw) is called before your adding code. > >> ixgbe_pf_reset_hw() calls hw->mac.ops.reset_hw( ) which may points to > following different function for different MAC type. > >> Ixgbe_reset_hw_82598( ) calls hw->phy.ops.init(hw) if > hw->phy.reset_disable == false . > >> Ixgbe_reset_hw_82599( ) calls hw->phy.ops.init(hw) unconditionally. > >> ixgbe_reset_hw_X540( ) doesn't' call pw->phy.ops.init(hw). For X540, > hw->phy.ops.init points to ixgbe_init_phy_ops_generic() which only initialize > some function pointers. > >> Ixgbe_rest_hw_x550em() calls hw->phy.ops.init(hw) unconditionally. > >> > >> And for VF, ixgbe_reset_hw_vf( ) and ixgbevf_hv_reset_hw_vf( ) don't > call hw->phy.ops.init(hw) anywhere. > >> > >> Thanks & Best Regards > >> -Wei > >> > >>> -Original Message- > >>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas > Monjalon > >>> Sent: Sunday, May 7, 2017 6:36 AM > >>> To: Srinivasan J > >>> Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, > >>> Konstantin > >>> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot > >>> swapped SFP/SFP+ > >>> > >>> 06/05/2017 15:51, Srinivasan J: > >>>> Hi, > >>>>Do we need an explicit "Acked-by" keyword for > >>>> this patch to be accepted and applied? > >>> > >>> Yes, given it is not a trivial patch, an ack from the maintainer is > >>> required. > >>> Anyway, it has been submitted too late for 17.05 testing.
Re: [dpdk-dev] [PATCH v7 0/5] Support NIC reset and keep same port id
Hi, Thomas Thanks for your expert guidance. I'll rework out v8 patch set to follow your guide and rebase to master brach. > -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Monday, July 17, 2017 3:26 AM > To: Dai, Wei > Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, > Konstantin ; Wu, Jingjing > ; Xing, Beilei ; Mcnamara, > John > Subject: Re: [dpdk-dev] [PATCH v7 0/5] Support NIC reset and keep same > port id > > 13/07/2017 17:53, Wei Dai: > > chagnes: > > v7: > > add description of NIC reset in doc/poll_mode_drv.rst > > Thanks for bringing more explanations. > The texts have to be reviewed by a native english speaker. > > About the organization of the doc, it is good to explain the VF use case in > the > prog guide as you do. But you should not add it to the doxygen. > The doxygen must be concise enough and explains only the API: > - when it can be called > - what a driver is doing when calling reset > - what is the expected state of the device after reset
Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset
> > Subject: RE: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC > > reset > > > > > > > + * A DPDK application also can call this function to trigger an > > > + initative > > > + * port reset. > > > > When apart from the above use case? Even if it is above case, we should > have some event to notify application to initiate the reset.Right? Without > the event, When or on what basics application needs to initiate reset? > > [Wei: Indeed, until now we didn't see any use case which DPDK application > initiative port reset itself. > > The most usual case is that PF is working with kernel driver and VFs are > working with DPDK PMD. > > Some operations on kernel PF lead to a PF reset which causes its VF reset. > > Anyway this new function provides a possibility for application to > > trigger an initiative port reset.] > > That's fine. The only concern part is when to call reset API from application. > Can we say on RTE_ETH_EVENT_INTR_RESET event, application needs to > call the reset API? I think, it is important to specify when application need > to > call this API, otherwise this api behavior will be tightly coupled with > underneath PMD. Side effect is, a new, non portable PMD specific API. > If a PMD wishes to fixup some overflow case(as an example), by invoking the > reset API from the application BUT same case may not valid for another > PMD hence it will create unexpected behavior from application based on the > underneath PMD. > > if RTE_ETH_EVENT_INTR_RESET event is not expected event to call the reset > API then create a new event or if it needs to be called in > RTE_ETH_EVENT_INTR_RESET then update the API documentation. Thanks for your feedback. I'll add description of this function in API doc in my v7 patch set. > > > > > > + *
Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset
> -Original Message- > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > Sent: Tuesday, July 11, 2017 1:17 PM > To: Dai, Wei > Cc: tho...@monjalon.net; Lu, Wenzhuo ; > Ananyev, Konstantin ; Wu, Jingjing > ; Xing, Beilei ; > dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset > > -Original Message- > > Date: Tue, 11 Jul 2017 01:57:15 + > > From: "Dai, Wei" > > To: Jerin Jacob > > CC: "tho...@monjalon.net" , "Lu, Wenzhuo" > > , "Ananyev, Konstantin" > > , "Wu, Jingjing" > > , "Xing, Beilei" , > > "dev@dpdk.org" > > Subject: RE: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC > > reset > > > > > > > + * A DPDK application also can call this function to trigger an > > > + initative > > > + * port reset. > > > > When apart from the above use case? Even if it is above case, we should > have some event to notify application to initiate the reset.Right? Without > the event, When or on what basics application needs to initiate reset? > > [Wei: Indeed, until now we didn't see any use case which DPDK application > initiative port reset itself. > > The most usual case is that PF is working with kernel driver and VFs are > working with DPDK PMD. > > Some operations on kernel PF lead to a PF reset which causes its VF reset. > > Anyway this new function provides a possibility for application to > > trigger an initiative port reset.] > > That's fine. The only concern part is when to call reset API from application. > Can we say on RTE_ETH_EVENT_INTR_RESET event, application needs to > call the reset API? I think, it is important to specify when application need > to > call this API, otherwise this api behavior will be tightly coupled with > underneath PMD. Side effect is, a new, non portable PMD specific API. > If a PMD wishes to fixup some overflow case(as an example), by invoking the > reset API from the application BUT same case may not valid for another > PMD hence it will create unexpected behavior from application based on the > underneath PMD. It is duty of PMD to trigger RTE_ETH_EVENT_INTR_RESET event and application should also register some callback function to handle this event. When PMD wants to trigger a reset, it can trigger RTE_ETH_EVENT_INTR_RESET. On the received event of RTE_ETH_EVENT_INTR_RESET, application can begin to handle it: stop working queues, make rx and tx function not be called and then call rte_eth_dev_reset( ). For thread safety, all these controlling operations had better be made in same thread. For example, when ixgbe PF is reset, PF send a message to notify VF this event and also trigger an interrupt to VF. And then in the interrupt service routine DPDK VF detect this notification message and calls _rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_RESET, NULL, NULL). So it means that PF reset trigger RTE_ETH_EVENT_INTR_RESET event in VF. The function _rte_eth_dev_callback_process( ) will call the registered callback function. The callback function can trigger application to handle all operations of VF reset including something like stopping working Rx/Tx queues and call this rte_eth_dev_reset(). The rte_eth_dev_reset( ) itself is generic function which only does some HW reset operations through calling dev_unint() and dev_init(). And itself doesn't handle above synchronization which is handled by application. PMD itself should not call rte_eth_dev_reset( ). PMD can trigger application to handle reset event. It is duty of application to handle all synchronization befort it calls rte_eth_dev_reset( ). > > if RTE_ETH_EVENT_INTR_RESET event is not expected event to call the reset > API then create a new event or if it needs to be called in > RTE_ETH_EVENT_INTR_RESET then update the API documentation. > Of course, when PMD wants to trigger a reset event, it can trigger other event other than RTE_ETH_EVENT_INTR_RESET. So the application should know which the alternate event is. This make application more complex. So it is suggested that only RTE_ETH_EVENT_INTR_RESET can be used to trigger a port reset. > > > > > + *
Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset
-Original Message- From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] Sent: Monday, July 10, 2017 7:35 PM To: Dai, Wei Cc: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev, Konstantin ; Wu, Jingjing ; Xing, Beilei ; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset -Original Message- > Date: Mon, 10 Jul 2017 18:05:41 +0800 > From: Wei Dai > To: tho...@monjalon.net, wenzhuo...@intel.com, > konstantin.anan...@intel.com, jingjing...@intel.com, > beilei.x...@intel.com > CC: dev@dpdk.org, Wei Dai > Subject: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset > X-Mailer: git-send-email 2.7.5 > > This patch adds a new eth_dev layer API function rte_eth_dev_reset(). > A DPDK application can call this function to reset a NIC and keep its > port id afterwards. > It means that all SW resources allocated in ethdev layer should be > kept and SW and HW resources of the NIC in PMD need to be reset in > similar way that it runs PCI dev_uninit() and then dev_init(). > The sequence of dev_uninit() and dev_init() can be packed into a > single interface API rte_eth_dev_reset(). > Please See the comments before the declaration of rte_eht_dev_reset() > in lib/librte_ether/rte_ethdev.h to get more details on why this > function is needed, what this function does and what an application > should do after calling this function. > > Signed-off-by: Wei Dai > --- > /** > + * Reset a Ethernet device and keep its port id. > + * > + * A DPDK application calls this function to do an initiative or > + passive > + * reset of a port. > + * > + * Sometimes a port have to be reset passively. For example a PF is > + reset, > + * all its VFs should also be reset by application itself to align > + with the > + * PF. May be I didn't understood this use case properly,But, PF can always send mailbox message to VF on PF reset. Right? [Wei: As to ixgbe, PF kernel driver always send mailbox message to VF when PF is reset. For other NICs, there are maybe other mechanism to notify VF of PF reset.] On such message from PF, VF can transparently reset without application knowledge(i.e rx and/or tx burst return zero) [Wei: VF reset is handling many HW registers which may have effect on working Rx/Tx path and may cause some unexpected behavior like crash. So application should make some operations like stopping Rx/Tx path before it begin VF reset. This is why application should handle VF reset itself.] > + * A DPDK application also can call this function to trigger an > + initative > + * port reset. When apart from the above use case? Even if it is above case, we should have some event to notify application to initiate the reset.Right? Without the event, When or on what basics application needs to initiate reset? [Wei: Indeed, until now we didn't see any use case which DPDK application initiative port reset itself. The most usual case is that PF is working with kernel driver and VFs are working with DPDK PMD. Some operations on kernel PF lead to a PF reset which causes its VF reset. Anyway this new function provides a possibility for application to trigger an initiative port reset.] > + *
Re: [dpdk-dev] [PATCH v5 2/4] net/ixgbe: add support of reset
Thanks, Thomas
I have just sent out my v6 patch set which includes more details to explain
why/what/when.
-Original Message-
From: Thomas Monjalon [mailto:tho...@monjalon.net]
Sent: Friday, July 7, 2017 4:36 PM
To: Dai, Wei ; Yigit, Ferruh
Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, Konstantin
; Wu, Jingjing ; Zhang,
Helin ; Peng, Yuan
Subject: Re: [dpdk-dev] [PATCH v5 2/4] net/ixgbe: add support of reset
07/07/2017 10:25, Thomas Monjalon:
> Hi,
>
> 30/06/2017 12:12, Wei Dai:
> > +/*
> > + * Reest PF device.
> > + */
> > +static int
> > +ixgbe_dev_reset(struct rte_eth_dev *dev) {
> > + int ret;
> > +
> > + /* To avoid unexpected behavior in VF, disable PF reset */
> > + if (dev->data->sriov.active)
> > + return -ENOTSUP;
> > +
> > + ret = eth_ixgbe_dev_uninit(dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = eth_ixgbe_dev_init(dev);
> > +
> > + return ret;
> > +}
>
> rte_eth_dev_reset() just do
> + rte_eth_dev_stop(port_id);
> + ret = dev->dev_ops->dev_reset(dev);
>
> and dev_reset() just do
> + ret = eth_ixgbe_dev_uninit(dev);
> + ret = eth_ixgbe_dev_init(dev);
>
> It is doing one more thing, the check of SR-IOV.
> Unfortunately, this restriction is not documented.
>
> This is the documentation of the new API:
>
> /**
> + * Reset a Ethernet device.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + */
> +int rte_eth_dev_reset(uint8_t port_id);
>
> It is really really too short.
> From the beginning of this proposal we are asking you to better
> explain why this API is needed. It still does not appear in the doc.
> Are you adding it to offer a new service to DPDK application developpers?
> Or is it just a secret sauce that you will explain only to your customers?
>
> This is what is expected to be documented:
> - why/when this API must be used
> - what the API will do
> - what is needed to do after
I would like to add that the description of the API must also help other PMD
maintainers to implement it.
Adding a new op means more work for PMD maintainers, that's why they should
understand the benefit and acknowledge it.
Ferruh, as the maintainer of next-net, please could you ask for feedbacks from
other PMD maintainers?
Re: [dpdk-dev] [PATCH v5 0/4] Support NIC reset and keep same port id
Hi, Thomas Would you please have a look at this patch set ? If any question, please let me know . Thanks -Wei -Original Message- From: Wu, Jingjing Sent: Friday, June 30, 2017 6:50 PM To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo ; Ananyev, Konstantin ; Zhang, Helin ; Peng, Yuan Cc: dev@dpdk.org Subject: RE: [PATCH v5 0/4] Support NIC reset and keep same port id > -Original Message- > From: Dai, Wei > Sent: Friday, June 30, 2017 6:13 PM > To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev, > Konstantin ; Wu, Jingjing > ; Zhang, Helin ; Peng, > Yuan > Cc: dev@dpdk.org; Dai, Wei > Subject: [PATCH v5 0/4] Support NIC reset and keep same port id > > Sometimes a port have to be reset. For example PF is reset, all its VF > should also be reset. After reset, if the port goes through PCI > remove() and then PCI probe() for restoration, its port id may be > changed and this is not expected by some customer DPDK application. > Normally, PCI probe() includes two parts: one is in rte_ethdev layer > and the other is calling PMD dev_init(). PCI remove( ) release all > resource allocated from rte_ethdev layer in PCI probe( ) and calls PMD > dev_unit( ). > To keep same port id and reset the port, only dev_uninit() and > dev_init( ) in PMD can be called and keep all resources allocated from > rte_ethdev layer poart in PCI probe( ). > > New rte_eth_dev_reset( ) calls rte_eth_dev_stop( ), PMD dev_uninit( ) > and then PMD dev_init( ) to reset a port and keep same port id. > And then application can go through rte_eth_dev_configure( ), > rte_eth_rx_queue_setup( ), rte_eth_tx_queue_setup( ) and > rte_eth_dev_start( ) again to restore its previous settings or to > reconfigure itself with different settings. > > To test this new feature, a testpmd command "port reset port_id" is added. > The mapping between port number and its PCI address can be monitored > to confirm its port number is kept. > And following test case can also be used to confirm the port can work > again after reset. > > A typical test steps are listed as follows: > For example, run "ifconfig PF-name down" will trigger a reset to VF. > 1. run testpmd with 2 ixgbe VF ports belonging to same PF 2. testpmd > > set verbose 1 //to observe VF working 3. testpmd > show port info > all //show port number and MAC addr 4. testpmd > start 5. let all > ports forwarding work for a while 6. testpmd > show port stats all 7. > ifconfig name-of-PF down 8. A message is shown in testmd to indicate > PF reset 9. ifconfig name-of-PF up 10. testpmd > stop // stop > forwarding to avoid crash during reset 11. testpmd > port reset all > 12. testpmd > port stop all 13. testpmd > port start all //recofnig > all ports 14. testpmd > show port info all > //get mapping of port id and MAC addr for forwarding 15. testpmd > > start // restore forwarding 14. let all ports forwarding work for a > while 15. testpmd > show port stats all //confirm all port can work > again 16. repeat above step 7 - 15 > > chagnes: > v5: > remove PCI address output to align with other modification which > will output it in other way > disable PF reset when its VF is ative to avoid unexpected VF > behavior > v4: > add PCI address to confirm its port number keep same > correct test method in cover letter > v3: > update testpmd command > v2: > only reset PMD layer resource and keep same port id, but > not restore settings > > Signed-off-by: Wei Dai > Tested-by: Yuan Peng Acked-by: Jingjing Wu
Re: [dpdk-dev] [PATCH v4 3/5] net/i40e: add support of reset
> -Original Message-
> From: Wu, Jingjing
> Sent: Friday, June 30, 2017 4:54 PM
> To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Zhang, Helin ;
> Peng, Yuan
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v4 3/5] net/i40e: add support of reset
>
> > }
> >
> > +static int
> > +i40e_dev_reset(struct rte_eth_dev *dev) {
> > + int ret;
> > +
> > + ret = eth_i40e_dev_uninit(dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = eth_i40e_dev_init(dev);
> > +
> > + return ret;
> Have you thought about if DPDK is working as host driver, and there Are VFs
> rely on it? If it doesn't support, at least a check should be added.
> Or you can add those check in Rte level.
If there is any VF, PF reset need sync with VF, but sync method may be much
different with different NIC type.
So, we'd like first reject PF reset if its VF exist.
I'll update it in v5 patch set.
>
> Thanks
> Jingjing
Re: [dpdk-dev] [PATCH v4 5/5] app/testpmd: enhance command to test NIC reset
Adding PCI address info here is to let user confirm mapping between PCI address
and port id is kept after reset.
As this is only for test purpose, are you OK for other part except these PCI
address printf ?
> -Original Message-
> From: Wu, Jingjing
> Sent: Friday, June 30, 2017 5:10 PM
> To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Zhang, Helin ;
> Peng, Yuan
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v4 5/5] app/testpmd: enhance command to test NIC reset
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Thursday, June 29, 2017 10:58 PM
> > To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev,
> > Konstantin ; Zhang, Helin
> > ; Wu, Jingjing ;
> > yuan.pntel.com
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v4 5/5] app/testpmd: enhance command to test NIC reset
> >
> > When PF is reset, a message will show it and all its VF need to be
> > reset.
> > User can run the command "port reset port_id"
> > to reset the VF port and to keep same port id without any
> > configuration. Then user can run "port stop port_id"
> > and "port start port_id" to reconfigure its forwarding mode and
> > parmaters as previous ones.
> > To avoid crash, current forwarding should be stopped before running
> > "port reset port_id".
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 10 ++--- app/test-pmd/testpmd.c | 61
> > +++---
> > app/test-pmd/testpmd.h | 1 +
> > 3 files changed, 66 insertions(+), 6 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > ff8ffd2..58ba6e4 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -950,6 +950,8 @@ static void cmd_operate_port_parsed(void
> *parsed_result,
> > stop_port(RTE_PORT_ALL);
> > else if (!strcmp(res->name, "close"))
> > close_port(RTE_PORT_ALL);
> > + else if (!strcmp(res->name, "reset"))
> > + reset_port(RTE_PORT_ALL);
> > else
> > printf("Unknown parameter\n");
> > }
> > @@ -959,7 +961,7 @@ cmdline_parse_token_string_t
> cmd_operate_port_all_cmd =
> > "port");
> > cmdline_parse_token_string_t cmd_operate_port_all_port =
> > TOKEN_STRING_INITIALIZER(struct cmd_operate_port_result, name,
> > - "start#stop#close");
> > + "start#stop#close#reset");
> > cmdline_parse_token_string_t cmd_operate_port_all_all =
> > TOKEN_STRING_INITIALIZER(struct cmd_operate_port_result, value,
> > "all");
> >
> > @@ -994,6 +996,8 @@ static void cmd_operate_specific_port_parsed(void
> *parsed_result,
> > stop_port(res->value);
> > else if (!strcmp(res->name, "close"))
> > close_port(res->value);
> > + else if (!strcmp(res->name, "reset"))
> > + reset_port(res->value);
> > else
> > printf("Unknown parameter\n");
> > }
> > @@ -1003,7 +1007,7 @@ cmdline_parse_token_string_t
> cmd_operate_specific_port_cmd =
> > keyword, "port");
> > cmdline_parse_token_string_t cmd_operate_specific_port_port =
> > TOKEN_STRING_INITIALIZER(struct cmd_operate_specific_port_result,
> > - name, "start#stop#close");
> > + name, "start#stop#close#reset");
> > cmdline_parse_token_num_t cmd_operate_specific_port_id =
> > TOKEN_NUM_INITIALIZER(struct cmd_operate_specific_port_result,
> > value, UINT8);
> > @@ -1011,7 +1015,7 @@ cmdline_parse_token_num_t
> > cmd_operate_specific_port_id = cmdline_parse_inst_t
> cmd_operate_specific_port = {
> > .f = cmd_operate_specific_port_parsed,
> > .data = NULL,
> > - .help_str = "port start|stop|close : Start/Stop/Close port_id",
> > + .help_str = "port start|stop|close|reset :
> > +Start/Stop/Close/Reset port_id",
> > .tokens = {
> > (void *)&cmd_operate_specific_port_cmd,
> > (void *)&cmd_operate_specific_port_port,
> > diff --git a/app/test-pmd/testpmd.c b/app/te
Re: [dpdk-dev] [PATCH v2 4/5] app/testpmd: add command to test NIC reset
> -Original Message-
> From: Wu, Jingjing
> Sent: Wednesday, June 28, 2017 5:11 PM
> To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Zhang, Helin
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v2 4/5] app/testpmd: add command to test NIC reset
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Tuesday, June 27, 2017 10:07 PM
> > To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev,
> > Konstantin ; Zhang, Helin
> > ; Wu, Jingjing
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v2 4/5] app/testpmd: add command to test NIC reset
> >
> > When a NIC is reset, a message will show it.
> > And then user can run the command "reset_port port_id"
> > to process it.
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 31 +++
> > app/test- pmd/config.c | 13 + app/test-pmd/testpmd.h |
> > 1 +
> > 3 files changed, 45 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > ff8ffd2..90f6bde 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -2588,6 +2588,36 @@ cmdline_parse_inst_t cmd_stop = {
> > },
> > };
> >
> > +/* *** reset a port *** */
> > +struct cmd_reset_port_result {
> > + cmdline_fixed_string_t command;
> > + uint8_t port_id;
> > +};
> > +
> > +static void cmd_reset_port_parsed(__attribute__((unused)) void
> > *parsed_result,
> > + __attribute__((unused)) struct cmdline *cl,
> > + __attribute__((unused)) void *data) {
> > + struct cmd_reset_port_result *res = parsed_result;
> > + reset_port(res->port_id);
> > +}
> > +
> > +cmdline_parse_token_string_t cmd_reset_port_cmd =
> > + TOKEN_STRING_INITIALIZER(struct cmd_reset_port_result, command,
> > +"reset_port"); cmdline_parse_token_num_t cmd_reset_port_id =
> > + TOKEN_NUM_INITIALIZER(struct cmd_reset_port_result, port_id,
> > UINT8);
> > +
> > +cmdline_parse_inst_t cmd_reset_port = {
> > + .f = cmd_reset_port_parsed,
> > + .data = NULL,
> > + .help_str = "reset_port ",
>
> You can just add one more option in the commands "port start|stop|close
> " and " port start|stop|close all"
> To "port start|stop|close|reset " and " port start|stop|close|reset
> all" instead of defining a new one.
Thanks for your feedback.
V3 patch set will follow your guide.
Re: [dpdk-dev] [PATCH v2 5/5] app/testpmd: add command to test NIC restoration
Thanks for your feedback. V3 patch set will follow your guide. > -Original Message- > From: Wu, Jingjing > Sent: Wednesday, June 28, 2017 5:05 PM > To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo > ; Ananyev, Konstantin > ; Zhang, Helin > Cc: dev@dpdk.org > Subject: RE: [PATCH v2 5/5] app/testpmd: add command to test NIC restoration > > > > > -----Original Message- > > From: Dai, Wei > > Sent: Tuesday, June 27, 2017 10:07 PM > > To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev, > > Konstantin ; Zhang, Helin > > ; Wu, Jingjing > > Cc: dev@dpdk.org; Dai, Wei > > Subject: [PATCH v2 5/5] app/testpmd: add command to test NIC > > restoration > > > > When a NIC is reset, a message will show it. > > And then user can run the command "reset_port port_id" > > to reset the port and to keep same port id without any without any > > configuration. > > This patch adds a testpmd command "reconfig_port port_id" > > to test whether the port can be reconfigured to have success Rx and Tx > function. > > The new command will configure the port with the simplest setting > > which includes only 1 Rx queue, only 1 Tx queue, Rx mode = None and Tx > > mode = None. > > It check if the port can receive and forward some packets. > > For example 100 packets in this new command. > > Before testing with "reset_port port_id" and then "reconfig_port > > port_id", current forwarding should be stopped first to avoid crash. > > > > Testpmd has mechanism to support reconfigure, you can check the > need_reconfig Field in port struct. > No need to define a new command. > > > Thanks > Jingjing
Re: [dpdk-dev] [PATCH v2 0/5] Support NIC reset and keep same port id
Many thanks to Yuan for your test support.
Your test show the code changes for rte_ether and driver/net can work as
expected.
I'll update a v3 patch set according to feedback from Wu Jingjing and your test.
In v3 patch, only code in testpmd will be changed but with similar test method.
> -Original Message-
> From: Peng, Yuan
> Sent: Thursday, June 29, 2017 11:52 AM
> To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Zhang, Helin ; Wu,
> Jingjing
> Cc: dev@dpdk.org; Dai, Wei
> Subject: RE: [dpdk-dev] [PATCH v2 0/5] Support NIC reset and keep same port id
>
> Tested-by: Peng, Yuan
>
> - Tested commit c1923afc0999b5b6f109190bc5b69b6c3d334635+the 5
> patches.
> - OS: 4.5.5-300.fc24.x86_64
> - GCC: gcc version 6.1.1 20160510 (Red Hat 6.1.1-2) (GCC)
> - CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
> - NIC: Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit
> SFI/SFP+
> Network Connection [8086:10fb] (rev 01)
> - Default x86_64-native-linuxapp-gcc configuration
> - Prerequisites:
> - Total 1cases, 1 passed, 0 failed
>
> Steps:
> DUT:
> 1. run testpmd with ixgbe VF
> echo 1 >/sys/bus/pci/devices/:07:00.0/sriov_numvfs
> ip link set ens786f0 vf 0 mac 00:11:22:33:44:11 ./usertools/dpdk-devbind.py -b
> vfio-pci 07:10.0 ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x3 -n 4 -- -i
>
> 2. testpmd > set verbose 1
> testpmd> set fwd rxonly
> testpmd> start
> tester:
> scapy
> >>> pkt1 = Ether(dst="00:11:22:33:44:11")/IP()/UDP()/Raw('x' * 20)
> >>> sendp(pkt1, iface="ens786f1", count=1)
> Vf can receive the packet correctly.
>
> 3. ifconfig ens786f0 down
> A message is shown in testmd to indicate PF reset:
> Port 0: Interrupt reset event
>
> 4. ifconfig ens786f0 up
>
> 5. testpmd > stop
>
> 6. testpmd > reset_port 0
>
> 7. testpmd> reconfig_port 0
> PMD: ixgbevf_dev_configure(): VF can't disable HW CRC Strip Port 0 MAC: 00
> 11 22 33 44 11 Begin to forward at least 100 packets to test reconfiguration
>
> 8. tester:
> >>> sendp(pkt1, iface="ens786f1", count=100)
>
> 9. Finish forwarding 100 packets to test reconfiguration
> testpmd> show port stats all
>
> NIC statistics for port 0
>
> RX-packets: 100RX-missed: 0 RX-bytes: 6200
> RX-errors: 0
> RX-nombuf: 0
> TX-packets: 0 TX-errors: 0 TX-bytes: 0
>
> Throughput (since last show)
> Rx-pps:0
> Tx-pps:0
>
>
> ########
>
> The vf can be reconfigured successfully after pf reset.
>
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> Sent: Tuesday, June 27, 2017 10:07 PM
> To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev,
> Konstantin ; Zhang, Helin
> ; Wu, Jingjing
> Cc: dev@dpdk.org; Dai, Wei
> Subject: [dpdk-dev] [PATCH v2 0/5] Support NIC reset and keep same port id
>
> Sometimes a port have to be reset. After reset, if the port goes through PCI
> remove() and then PCI probe() for restoration, its port id may be changed and
> this is not expected by some customer DPDK application.
> Normally, PCI probe() includes two parts: one is in rte_ethdev layer and the
> other is calling PMD dev_init(). PCI remove( ) release all resource allocated
> from rte_ethdev layer in PCI probe( ) and calls PMD dev_unit( ).
> To keep same port id and reset the port, only dev_uninit() and dev_init( ) in
> PMD can be called and keep all resources allocated from rte_ethdev layer poart
> in PCI probe( ).
>
> New rte_eth_dev_reset( ) calls rte_eth_dev_stop( ), PMD dev_uninit( ) and
> then PMD dev_init( ) to reset a port and keep same port id.
> And then application can go through rte_eth_dev_configure( ),
> rte_eth_rx_queue_setup( ), rte_eth_tx_queue_setup( ) and
> rte_eth_dev_start( ) again to restore its previous settings or to reconfigure
> itself with different settings.
>
> To test this new feature, 2 testpmd commands are introduced.
> The first command "reset_port port_id" calls rte_eth_dev_reset( ).
> The second command "reconfig_port port_id" is used to test if the port can be
> reconfigured successfully. This command configure the port with the simplest
> settings include only 1 Rx queue, only 1 Tx queue, Rx mode = None and Tx mode
> = None. It check port by receving at least
> 100 packets and then forward these packets from itself.
>
> A typical test steps are listed as follows:
> For example, run "ifconfig
Re: [dpdk-dev] [PATCH 7/7] net/i40e: add support of restoration
> -Original Message-
> From: Wu, Jingjing
> Sent: Wednesday, June 7, 2017 3:50 PM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Ananyev, Konstantin ; Zhang, Helin
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH 7/7] net/i40e: add support of restoration
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Saturday, May 27, 2017 4:22 PM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> > ; Zhang, Helin ;
> > Wu, Jingjing
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH 7/7] net/i40e: add support of restoration
> >
> > export dev_uninit and dev_init for restoration to reset port but keep
> > same port id.
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/i40e/i40e_ethdev.c| 2 ++
> > drivers/net/i40e/i40e_ethdev_vf.c | 5 +
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 4c49673..9512ca4 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -449,6 +449,8 @@ static const struct eth_dev_ops i40e_eth_dev_ops =
> {
> > .dev_start= i40e_dev_start,
> > .dev_stop = i40e_dev_stop,
> > .dev_close= i40e_dev_close,
> > + .dev_init = eth_i40e_dev_init,
> > + .dev_uninit = eth_i40e_dev_uninit,
> > .promiscuous_enable = i40e_dev_promiscuous_enable,
> > .promiscuous_disable = i40e_dev_promiscuous_disable,
> > .allmulticast_enable = i40e_dev_allmulticast_enable,
>
>
> you can just get int and unint func point by eth_dev->driver.eth_dev_init and
> eth_dev->driver.eth_dev_init
>
> No need to define ops here.
I'm sorry that struct rte_eth_dev doesn't have member driver.
The struct rte_eth_dev_data, struct rte_pci_device and struct rte_pci_device
don't have
Any member to refer dev_init() and dev_uninit.
Re: [dpdk-dev] [PATCH v4 05/19] net/ixgbe: properly reference PCI header
Why to introduce this change ? Even without this patch, all files can be built successfully. Each.*.o.d files in x86_64-native-linuxapp-gcc keeps same in both with and without this patch. So there is no need to add the line at least in the config of x86_64-native-linuxapp-gcc. > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gaetan Rivet > Sent: Thursday, June 8, 2017 7:57 AM > To: dev@dpdk.org > Cc: Gaetan Rivet > Subject: [dpdk-dev] [PATCH v4 05/19] net/ixgbe: properly reference PCI header > > Signed-off-by: Gaetan Rivet > --- > drivers/net/ixgbe/ixgbe_ethdev.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h > b/drivers/net/ixgbe/ixgbe_ethdev.h > index e2d0139..bb5ecd5 100644 > --- a/drivers/net/ixgbe/ixgbe_ethdev.h > +++ b/drivers/net/ixgbe/ixgbe_ethdev.h > @@ -39,6 +39,7 @@ > #include "ixgbe_bypass.h" > #include > #include > +#include > > /* need update link, bit flag */ > #define IXGBE_FLAG_NEED_LINK_UPDATE (uint32_t)(1 << 0) > -- > 2.1.4
Re: [dpdk-dev] [PATCH v2] ethdev: moved bypass functions to ixgbe pmd
No other NIC has bypass functions except ixgbe,
so I agree moving them from ethdev to ixgbe pmd.
As these functions are exported to external upper layer application,
it is necessary to use is_ixgbe_supported() to avoid be called by
other type of NIC.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Lu, Wenzhuo
> Sent: Wednesday, May 31, 2017 11:30 AM
> To: Nicolau, Radu ; dev@dpdk.org
> Cc: Yigit, Ferruh ; Iremonger, Bernard
> ; Nicolau, Radu
> Subject: Re: [dpdk-dev] [PATCH v2] ethdev: moved bypass functions to ixgbe
> pmd
>
> Hi Radu,
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Radu Nicolau
> > Sent: Monday, May 29, 2017 11:23 PM
> > To: dev@dpdk.org
> > Cc: Yigit, Ferruh; Iremonger, Bernard; Nicolau, Radu
> > Subject: [dpdk-dev] [PATCH v2] ethdev: moved bypass functions to ixgbe
> > pmd
> >
> > Moved all bypass functions to ixgbe pmd and removed function pointers
> > from the eth_dev_ops struct.
> >
> > Changes in v2:
> > CONFIG_RTE_NIC_BYPASS removed, new option in the IXGBE section added,
> > CONFIG_RTE_LIBRTE_IXGBE_BYPASS.
> > Updated test-pmd to always include the bypass commands.
> >
> > Signed-off-by: Radu Nicolau
>
>
> > diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.c
> > b/drivers/net/ixgbe/rte_pmd_ixgbe.c
> > index e8fc9a6..efcaf68 100644
> > --- a/drivers/net/ixgbe/rte_pmd_ixgbe.c
> > +++ b/drivers/net/ixgbe/rte_pmd_ixgbe.c
> > @@ -908,3 +908,109 @@ rte_pmd_ixgbe_set_tc_bw_alloc(uint8_t port,
> >
> > return 0;
> > }
> > +
> > +#ifdef RTE_LIBRTE_IXGBE_BYPASS
> > +int
> > +rte_pmd_ixgbe_bypass_init(uint8_t port_id) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> Please reference the existing code to check "is_ixgbe_supported" here.
> Because this API may be called by APP directly.
> The same comments for all the other APIs below.
>
> > +
> > + dev = &rte_eth_devices[port_id];
> > + ixgbe_bypass_init(dev);
> > + return 0;
> > +}
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_state_show(uint8_t port_id, uint32_t *state) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_state_show(dev, state); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_state_set(uint8_t port_id, uint32_t *new_state) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_state_store(dev, new_state); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_event_show(uint8_t port_id,
> > + uint32_t event,
> > + uint32_t *state)
> > +{
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_event_show(dev, event, state); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_event_store(uint8_t port_id,
> > +uint32_t event,
> > +uint32_t state)
> > +{
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_event_store(dev, event, state); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_wd_timeout_store(uint8_t port_id, uint32_t
> > +timeout) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_wd_timeout_store(dev, timeout); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_ver_show(uint8_t port_id, uint32_t *ver) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_ver_show(dev, ver); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_wd_timeout_show(uint8_t port_id, uint32_t
> > +*wd_timeout) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_wd_timeout_show(dev, wd_timeout); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_wd_reset(uint8_t port_id) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_wd_reset(dev);
> > +}
>
Re: [dpdk-dev] 2nd try: problem with ixgbe_dev_link_update() for multi-speed fiber [was] Re: [PATCH v4] net/ixgbe: ensure link status is updated
Hi, Roger
Sorry for typo error. You should set --log-level=8
Regards
-Wei
> -Original Message-
> From: Dai, Wei
> Sent: Tuesday, May 23, 2017 3:24 PM
> To: 'Roger B. Melton' ; Laurent Hardy
> ; dev@dpdk.org
> Cc: Yigit, Ferruh ; Zhang, Helin
> ; Ananyev, Konstantin
> ; olivier.m...@6wind.com
> Subject: RE: 2nd try: problem with ixgbe_dev_link_update() for multi-speed
> fiber [was] Re: [dpdk-dev] [PATCH v4] net/ixgbe: ensure link status is updated
>
> Hi, Roger
> Sorry for late response as we are busy with other higher priority task.
> ixgbe_setup_mac_link_multispeed_fiber( ) in ixgbe_common.c calls
> ixgbe_setup_mac_link( ) which some functions defined in ixgbe/base .
> Would you please give us more info to narrow down this issue ?
>
> What device id did you use to trigger this issue ?
>
> To get more info, would you please change
> "CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n" to "
> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=y" in config/common_base And
> run your application with EAL parameter --log-level=7 to get trace path of
> ixgbe functions for us.
>
> Thanks & Best Regards
> -Wei
>
>
> > -Original Message-
> > From: Roger B. Melton [mailto:rmel...@cisco.com]
> > Sent: Tuesday, May 23, 2017 2:54 AM
> > To: Laurent Hardy ; dev@dpdk.org; Dai, Wei
> >
> > Cc: Yigit, Ferruh ; Zhang, Helin
> > ; Ananyev, Konstantin
> > ; olivier.m...@6wind.com
> > Subject: 2nd try: problem with ixgbe_dev_link_update() for multi-speed
> > fiber [was] Re: [dpdk-dev] [PATCH v4] net/ixgbe: ensure link status is
> > updated
> >
> > Hi Laurent/Wei,
> >
> > Any thoughts?
> >
> > Regards,
> > Roger
> >
> >
> > On 5/17/17 9:31 AM, Roger B Melton wrote:
> > > Hi Laurent/Wei,
> > >
> > > As I continue to integrate DPDK 17.05 into my application, I have
> > > hit another issue with this patch while testing in a VM with
> > > multispeed fiber ixgbe PCI passthrough. My application periodically
> > > invokes
> > > rte_eth_link_get_nowait() to detect link state changes. If the link
> > > is down (no cable or far end disabled), ixgbe_setup_link() will not
> > > return for ~1.3seconds due to the link setup algorithm in
> > > ixgbe_common.c:ixgbe_multispeed_fiber():
> > >
> > > +if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> > > +hw->mac.ops.get_media_type(hw) == ixgbe_media_type_fiber) {
> > > +speed = hw->phy.autoneg_advertised;
> > > +if (!speed)
> > > +ixgbe_get_link_capabilities(hw, &speed, &autoneg);
> > > +ixgbe_setup_link(hw, speed, true); +}
> > > +
> > >
> > > I have two questions:
> > >
> > > * Shouldn't we avoid the link setup cost if the caller has specified
> > >not to wait_to_complete?
> > > * If the concern is speed may not be properly configured, shouldn't
> > >the link setup be deferred until state changes link up thus
> > >minimizing the delays enforced in ixgbe_multispeed_fiber()?
> > >
> > >
> > > Regards,
> > > -Roger
> > >
> > >
> > >
> > >
> > > On 4/27/17 11:03 AM, Laurent Hardy wrote:
> > >> In case of fiber and link speed set to 1Gb at peer side (with
> > >> autoneg or with defined speed), link status could be not properly
> > >> updated at time cable is plugged-in.
> > >> Indeed if cable was not plugged when device has been configured and
> > >> started then link status will not be updated properly with new
> > >> speed as no link setup will be triggered.
> > >>
> > >> To avoid this issue, IXGBE_FLAG_NEED_LINK_CONFIG is set to try a
> > >> link setup each time link_update() is triggered and current link
> > >> status is down. When cable is plugged-in, link setup will be
> > >> performed via ixgbe_setup_link().
> > >>
> > >> Signed-off-by: Laurent Hardy
> > >> ---
> > >> Hi Wei, please find enclosed patch v4, tested using testpmd.
> > >>
> > >> v1 -> v2:
> > >> - rebase on top of head (change flag to 1<<4)
> > >> - fix regression with copper links: only update link for fiber
> > >> links
> > >>
> > >> v2 -> v3:
> > >> - remove unnescessary check on speed mask if autoneg is false
> > >>
> > >> v3 -> v4:
> > &g
Re: [dpdk-dev] 2nd try: problem with ixgbe_dev_link_update() for multi-speed fiber [was] Re: [PATCH v4] net/ixgbe: ensure link status is updated
Hi, Roger
Sorry for late response as we are busy with other higher priority task.
ixgbe_setup_mac_link_multispeed_fiber( ) in ixgbe_common.c calls
ixgbe_setup_mac_link( ) which some functions defined in ixgbe/base .
Would you please give us more info to narrow down this issue ?
What device id did you use to trigger this issue ?
To get more info, would you please change
"CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n" to "
CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=y" in config/common_base
And run your application with EAL parameter --log-level=7 to get trace path of
ixgbe functions for us.
Thanks & Best Regards
-Wei
> -Original Message-
> From: Roger B. Melton [mailto:rmel...@cisco.com]
> Sent: Tuesday, May 23, 2017 2:54 AM
> To: Laurent Hardy ; dev@dpdk.org; Dai, Wei
>
> Cc: Yigit, Ferruh ; Zhang, Helin
> ; Ananyev, Konstantin
> ; olivier.m...@6wind.com
> Subject: 2nd try: problem with ixgbe_dev_link_update() for multi-speed fiber
> [was] Re: [dpdk-dev] [PATCH v4] net/ixgbe: ensure link status is updated
>
> Hi Laurent/Wei,
>
> Any thoughts?
>
> Regards,
> Roger
>
>
> On 5/17/17 9:31 AM, Roger B Melton wrote:
> > Hi Laurent/Wei,
> >
> > As I continue to integrate DPDK 17.05 into my application, I have hit
> > another issue with this patch while testing in a VM with multispeed
> > fiber ixgbe PCI passthrough. My application periodically invokes
> > rte_eth_link_get_nowait() to detect link state changes. If the link
> > is down (no cable or far end disabled), ixgbe_setup_link() will not
> > return for ~1.3seconds due to the link setup algorithm in
> > ixgbe_common.c:ixgbe_multispeed_fiber():
> >
> > +if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> > +hw->mac.ops.get_media_type(hw) == ixgbe_media_type_fiber) {
> > +speed = hw->phy.autoneg_advertised;
> > +if (!speed)
> > +ixgbe_get_link_capabilities(hw, &speed, &autoneg);
> > +ixgbe_setup_link(hw, speed, true); +}
> > +
> >
> > I have two questions:
> >
> > * Shouldn't we avoid the link setup cost if the caller has specified
> >not to wait_to_complete?
> > * If the concern is speed may not be properly configured, shouldn't
> >the link setup be deferred until state changes link up thus
> >minimizing the delays enforced in ixgbe_multispeed_fiber()?
> >
> >
> > Regards,
> > -Roger
> >
> >
> >
> >
> > On 4/27/17 11:03 AM, Laurent Hardy wrote:
> >> In case of fiber and link speed set to 1Gb at peer side (with autoneg
> >> or with defined speed), link status could be not properly updated at
> >> time cable is plugged-in.
> >> Indeed if cable was not plugged when device has been configured and
> >> started then link status will not be updated properly with new speed
> >> as no link setup will be triggered.
> >>
> >> To avoid this issue, IXGBE_FLAG_NEED_LINK_CONFIG is set to try a link
> >> setup each time link_update() is triggered and current link status is
> >> down. When cable is plugged-in, link setup will be performed via
> >> ixgbe_setup_link().
> >>
> >> Signed-off-by: Laurent Hardy
> >> ---
> >> Hi Wei, please find enclosed patch v4, tested using testpmd.
> >>
> >> v1 -> v2:
> >> - rebase on top of head (change flag to 1<<4)
> >> - fix regression with copper links: only update link for fiber links
> >>
> >> v2 -> v3:
> >> - remove unnescessary check on speed mask if autoneg is false
> >>
> >> v3 -> v4:
> >> - remove default speed set to 10Gb if autoneg is false, rely on
> >> ixgbe_get_link_capabilities( ) instead.
> >> ---
> >> drivers/net/ixgbe/ixgbe_ethdev.c | 14 ++
> >> drivers/net/ixgbe/ixgbe_ethdev.h | 1 +
> >> 2 files changed, 15 insertions(+)
> >>
> >> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> >> b/drivers/net/ixgbe/ixgbe_ethdev.c
> >> index 7b856bb..8a0c0a7 100644
> >> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> >> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> >> @@ -3782,8 +3782,12 @@ ixgbe_dev_link_update(struct rte_eth_dev
> *dev,
> >> int wait_to_complete)
> >> struct ixgbe_hw *hw =
> >> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> >> struct rte_eth_link link, old;
> >> ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
> >> +struct ixgbe_interrupt *intr =
> >> + IXGBE_DEV_PRIVA
Re: [dpdk-dev] [PATCH] examples/helloworld: add output of core id and socket id
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, May 17, 2017 10:16 PM
> To: Dai, Wei ; Richardson, Bruce
> ; Mcnamara, John
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples/helloworld: add output of core id and
> socket id
>
> On 5/17/2017 2:49 PM, Wei Dai wrote:
> > Adding output of core id and socket id of each lcore/pthread can help
> > to understand their relationship.
> > And this can also help to examine the usage of the EAL lcore settings
> > like -c, -l and --lcore .
> >
> > Signed-off-by: Wei Dai
> > ---
> > examples/helloworld/main.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/examples/helloworld/main.c b/examples/helloworld/main.c
> > index 8b7a2de..fdd8818 100644
> > --- a/examples/helloworld/main.c
> > +++ b/examples/helloworld/main.c
> > @@ -50,7 +50,9 @@ lcore_hello(__attribute__((unused)) void *arg) {
> > unsigned lcore_id;
> > lcore_id = rte_lcore_id();
> > - printf("hello from core %u\n", lcore_id);
> > + printf("hello from core %2u at core_id = %2u on socket_id = %2u\n",
>
> It is hard to understand difference from "core" and "core_id", what do you
> think using "lcore" and "core" respectively in the message?
Yes, it is still a bit confused.
I should change it to printf("hello from lcore_id = %2u at core_id = %2u on
socket_id = %2u\n",
>
> > + lcore_id, lcore_config[lcore_id].core_id,
> > + lcore_config[lcore_id].socket_id);
> > return 0;
> > }
> >
> >
Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
Hi, Srini There is a bit confusion. Your patch shows that your code is added into the function eth_ixgbevf_pci_remove( ). But it is not. It is added into the fucntion ixgbe_dev_start( ), right ? So would you please rebase it to R 17.05 ? Which type of ixgbe device id did you tested ? There are many MAC types with different device id. The function ixgbe_pf_reset_hw(hw) is called before your adding code. ixgbe_pf_reset_hw() calls hw->mac.ops.reset_hw( ) which may points to following different function for different MAC type. Ixgbe_reset_hw_82598( ) calls hw->phy.ops.init(hw) if hw->phy.reset_disable == false . Ixgbe_reset_hw_82599( ) calls hw->phy.ops.init(hw) unconditionally. ixgbe_reset_hw_X540( ) doesn't' call pw->phy.ops.init(hw). For X540, hw->phy.ops.init points to ixgbe_init_phy_ops_generic() which only initialize some function pointers. Ixgbe_rest_hw_x550em() calls hw->phy.ops.init(hw) unconditionally. And for VF, ixgbe_reset_hw_vf( ) and ixgbevf_hv_reset_hw_vf( ) don't call hw->phy.ops.init(hw) anywhere. Thanks & Best Regards -Wei > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon > Sent: Sunday, May 7, 2017 6:36 AM > To: Srinivasan J > Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, > Konstantin > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped > SFP/SFP+ > > 06/05/2017 15:51, Srinivasan J: > > Hi, > >Do we need an explicit "Acked-by" keyword for this > > patch to be accepted and applied? > > Yes, given it is not a trivial patch, an ack from the maintainer is required. > Anyway, it has been submitted too late for 17.05 testing.
Re: [dpdk-dev] bug in net/ixgbe/ixgbe_ethdev.c:ixgbe_dev_link_update beginning in 17.05-rc3?
Yes, it is a bug.
The hw->mac.ops.get_media_type of ixgbe VF is NULL.
I have just submitted a patch to fix it.
http://dpdk.org/dev/patchwork/patch/24188/
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Roger B Melton
> Sent: Wednesday, May 10, 2017 1:53 AM
> To: dev@dpdk.org; laurent.ha...@6wind.com
> Subject: [dpdk-dev] bug in net/ixgbe/ixgbe_ethdev.c:ixgbe_dev_link_update
> beginning in 17.05-rc3?
>
> After updating to 17.05-rc4 I hit a crash in
> drivers/net/ixgbe/ixgbe_ethdev.c:ixgbe_dev_link_update(). The issue was
> a NULL get_media_type FV for the VF driver.
>
> Looking at recent commits, I see the following added the
> get_media_type() check:
>
> commit c12d22f65b132c56db7b4fdbfd5ddce27d1e9572
> Author: Laurent Hardy
> Date: Thu Apr 27 17:03:42 2017 +0200
>
> @@ -3793,6 +3797,14 @@ ixgbe_dev_link_update(struct
> rte_eth_dev
> *dev, int wait_to_complete)
>
> hw->mac.get_link_status = true;
>
> + if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> + hw->mac.ops.get_media_type(hw) ==
> ixgbe_media_type_fiber) {
> + speed = hw->phy.autoneg_advertised;
> + if (!speed)
> + ixgbe_get_link_capabilities(hw,
> &speed,
> &autoneg);
> + ixgbe_setup_link(hw, speed, true);
> + }
> +
>
> This is fine for the PF driver, but we shouldn't invoke get_media_type
> for the VF.
>
>
> Laurent,
>
> Is this a bug, or am I missing something? If it is a bug, what's the
> proper fix?
>
> Regards,
> Roger
>
>
>
>
> --
>
>
>
> |Roger B. Melton| | Cisco Systems
> |
> |CPP Software :|::|: 7100 Kit Creek Rd |
> |+1.919.476.2332 phone:|||: :|||:RTP, NC 27709-4987 |
> |+1.919.392.1094 fax .:|||:..:|||:. rmel...@cisco.com |
> |
> |
> | This email may contain confidential and privileged material for the|
> | sole use of the intended recipient. Any review, use, distribution |
> | or disclosure by others is strictly prohibited. If you are not the |
> | intended recipient (or authorized to receive for the recipient), |
> | please contact the sender by reply email and delete all copies of |
> | this message.
> |
> |
> |
> | For corporate legal information go to: |
> | http://www.cisco.com/web/about/doing_business/legal/cri/index.html |
> |__ http://www.cisco.com
> |
Re: [dpdk-dev] [PATCH v2 0/3] add a macro to enable support of backtrace
Hi, Thomas I noticed that my following patch set has been superseded. It address the compile errors when DPDK is built with musl. I know some customer products like Yocto Linux and that from Roph are using DPDK with musl and they have to manually change something to build it. Roph also referenced to use DPDK with musl in his mail titled " [dpdk-dev] Compiling DPDK 17.02 using musl instead of glibc " sent on 2017-03-14 Thanks & Best Regards -Wei > -Original Message----- > From: Dai, Wei > Sent: Monday, March 13, 2017 4:59 PM > To: dev@dpdk.org > Cc: thomas.monja...@6wind.com; Mcnamara, John > ; david.march...@6wind.com; Tan, Raymond > ; Dai, Wei > Subject: [PATCH v2 0/3] add a macro to enable support of backtrace > > Some LIBC implementation like musl doesn't support backtrace( ) and > backtrace_symbols declared in execinfo.h. > Currently some DPDK customers fail to build PDDK with musl. > In order to build DPDK with musl, there is a need to reomve references > toexecinfo.h. > > Add a configuration parameter in config/common_linuxapp which equals to y by > default. It also generate a macro named as RTE_EAL_ENABLE_BACKTRACE > when this configuration paramter equals to y or no above macro when it is n. > > --- > changes: > v2 -- change configuration parameter name > > > Wei Dai (3): > examples/performance-thread: remove reference to execinfo.h > config: add a marco to enable backtrace or not > eal: remove references to execinfo.h for musl > > config/common_linuxapp | 1 + > examples/performance-thread/common/lthread_tls.c | 1 - > lib/librte_eal/linuxapp/eal/eal_debug.c | 4 > 3 files changed, 5 insertions(+), 1 deletion(-) > > -- > 2.7.4
