Re: [dpdk-dev] eth_fm10k_dev_init failed as there is no Glort update
> -Original Message-
> From: Krishna S [mailto:k.shar...@gmail.com]
> Sent: Thursday, August 17, 2017 6:33 PM
> To: Chen, Jing D
> Cc: dev@dpdk.org; Wang, Xiao W
> Subject: Re: eth_fm10k_dev_init failed as there is no Glort update
>
> We are having kernel fm10k PF + fm10k VF driver. We are getting the
> update(glort updated) in all the cases in most of the times.
> But randomly, we are seeing this issue in one of VF initialisation.
>
> The frequency of issue is, say 1 in 20 times.
This is DPDK community, kernel driver is not in the scope.
Please turn to kernel community or ask local technical support from Intel.
>
>
> On Thu, Aug 17, 2017 at 2:44 PM, Chen, Jing D
> wrote:
> > Some corretness.
> >
> >> -Original Message-
> >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Chen, Jing D
> >> Sent: Thursday, August 17, 2017 5:06 PM
> >> To: Krishna S
> >> Cc: dev@dpdk.org; Wang, Xiao W
> >> Subject: Re: [dpdk-dev] eth_fm10k_dev_init failed as there is no
> >> Glort update
> >>
> >> Hi,
> >>
> >> > -Original Message-
> >> > From: Krishna S [mailto:k.shar...@gmail.com]
> >> > Sent: Thursday, August 17, 2017 5:02 PM
> >> > To: Chen, Jing D
> >> > Cc: dev@dpdk.org; Wang, Xiao W
> >> > Subject: Re: eth_fm10k_dev_init failed as there is no Glort update
> >> >
> >> > Hi Everyone,
> >> >
> >> > Can anyone help me on this?
> >> >
> >> > Regards,
> >> > Krishna Sharma
> >> >
> >> > On Wed, Aug 16, 2017 at 7:24 PM, Krishna S
> >> wrote:
> >> > > Hi Cheng,
> >> > >
> >> > > I am working on a system which uses fm10k driver.
> >> > >
> >> > > In my system, I am hitting an error in eth_fm10k_dev_init().
> >> > >
> >> > > We are waiting for VF to get GLoRT update message once
> >> > > update_lport_state(hw, hw->mac.dglort_map, 1, 1); is done.
> >> > >
> >> > > Check goes something like this.
> >> > > if (hw->mac.type == fm10k_mac_vf) {
> >> > > int glort_valid = 0;
> >> > > int i;
> >> > >
> >> > > for (i = 0; i < MAX_QUERY_GLORT_STATE_TIMES; i++) {
> >> > > glort_valid = fm10k_glort_valid(hw);
> >> > > if (glort_valid) {
> >> > > PMD_INIT_LOG(INFO, "GloRT update took
> >> > > ~%u ms!",
> >> > > (i * WAIT_GLORT_MSG_US/1000));
> >> > > break;
> >> > > }
> >> > >
> >> > > But we are at times failing to get an update and so initialising fails.
> >> > >
> >> > > Could you kindly give pointers on what could be possible reasons
> >> > > why is there no update from PF ?
> >>
> >> DPDK doesn't support DPDK PF + DPDK VF case, only kernel PF +
> >> DPDK/kernel VF driver case.
> >
> > fm10k doesn't support DPDK fm10k PF + DPDK fm10k VF case, only kernel
> > fm10k PF + DPDK/kernel fm10k VF driver case.
> >
> >>
> >> > >
> >> > >
> >> > > --
> >> > > Regards,
> >> > > Krishna Sharma
> >> >
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Krishna Sharma
>
>
>
> --
> Regards,
> Krishna Sharma
Re: [dpdk-dev] eth_fm10k_dev_init failed as there is no Glort update
Some corretness.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Chen, Jing D
> Sent: Thursday, August 17, 2017 5:06 PM
> To: Krishna S
> Cc: dev@dpdk.org; Wang, Xiao W
> Subject: Re: [dpdk-dev] eth_fm10k_dev_init failed as there is no Glort update
>
> Hi,
>
> > -Original Message-
> > From: Krishna S [mailto:k.shar...@gmail.com]
> > Sent: Thursday, August 17, 2017 5:02 PM
> > To: Chen, Jing D
> > Cc: dev@dpdk.org; Wang, Xiao W
> > Subject: Re: eth_fm10k_dev_init failed as there is no Glort update
> >
> > Hi Everyone,
> >
> > Can anyone help me on this?
> >
> > Regards,
> > Krishna Sharma
> >
> > On Wed, Aug 16, 2017 at 7:24 PM, Krishna S
> wrote:
> > > Hi Cheng,
> > >
> > > I am working on a system which uses fm10k driver.
> > >
> > > In my system, I am hitting an error in eth_fm10k_dev_init().
> > >
> > > We are waiting for VF to get GLoRT update message once
> > > update_lport_state(hw, hw->mac.dglort_map, 1, 1); is done.
> > >
> > > Check goes something like this.
> > > if (hw->mac.type == fm10k_mac_vf) {
> > > int glort_valid = 0;
> > > int i;
> > >
> > > for (i = 0; i < MAX_QUERY_GLORT_STATE_TIMES; i++) {
> > > glort_valid = fm10k_glort_valid(hw);
> > > if (glort_valid) {
> > > PMD_INIT_LOG(INFO, "GloRT update took ~%u
> > > ms!",
> > > (i * WAIT_GLORT_MSG_US/1000));
> > > break;
> > > }
> > >
> > > But we are at times failing to get an update and so initialising fails.
> > >
> > > Could you kindly give pointers on what could be possible reasons why
> > > is there no update from PF ?
>
> DPDK doesn't support DPDK PF + DPDK VF case, only kernel PF + DPDK/kernel
> VF driver case.
fm10k doesn't support DPDK fm10k PF + DPDK fm10k VF case, only kernel fm10k PF
+ DPDK/kernel
fm10k VF driver case.
>
> > >
> > >
> > > --
> > > Regards,
> > > Krishna Sharma
> >
> >
> >
> > --
> > Regards,
> > Krishna Sharma
Re: [dpdk-dev] eth_fm10k_dev_init failed as there is no Glort update
Hi,
> -Original Message-
> From: Krishna S [mailto:k.shar...@gmail.com]
> Sent: Thursday, August 17, 2017 5:02 PM
> To: Chen, Jing D
> Cc: dev@dpdk.org; Wang, Xiao W
> Subject: Re: eth_fm10k_dev_init failed as there is no Glort update
>
> Hi Everyone,
>
> Can anyone help me on this?
>
> Regards,
> Krishna Sharma
>
> On Wed, Aug 16, 2017 at 7:24 PM, Krishna S wrote:
> > Hi Cheng,
> >
> > I am working on a system which uses fm10k driver.
> >
> > In my system, I am hitting an error in eth_fm10k_dev_init().
> >
> > We are waiting for VF to get GLoRT update message once
> > update_lport_state(hw, hw->mac.dglort_map, 1, 1); is done.
> >
> > Check goes something like this.
> > if (hw->mac.type == fm10k_mac_vf) {
> > int glort_valid = 0;
> > int i;
> >
> > for (i = 0; i < MAX_QUERY_GLORT_STATE_TIMES; i++) {
> > glort_valid = fm10k_glort_valid(hw);
> > if (glort_valid) {
> > PMD_INIT_LOG(INFO, "GloRT update took ~%u
> > ms!",
> > (i * WAIT_GLORT_MSG_US/1000));
> > break;
> > }
> >
> > But we are at times failing to get an update and so initialising fails.
> >
> > Could you kindly give pointers on what could be possible reasons why
> > is there no update from PF ?
DPDK doesn't support DPDK PF + DPDK VF case, only kernel PF + DPDK/kernel VF
driver case.
> >
> >
> > --
> > Regards,
> > Krishna Sharma
>
>
>
> --
> Regards,
> Krishna Sharma
Re: [dpdk-dev] [PATCH v3] test: add delay time in test alarm
> >
> > -Original Message-
> > From: Yang, Qiming
> > Sent: Tuesday, June 20, 2017 11:24 AM
> > To: dev@dpdk.org
> > Cc: Chen, Jing D ; Wu, Jingjing
> > ; Yang, Qiming
> > Subject: [PATCH v3] test: add delay time in test alarm
> >
> > Because accuracy of timing to the microsecond is not guaranteed in
> > rte_eal_alarm_set, this function will not be called before the
> > requested time, but may be called a period of time afterwards which
> > can not be calculated. In order to ensure test alarm running success,
> > this patch added the delay time before check the flag.
> >
> > Signed-off-by: Qiming Yang
> > ---
> > v2 changes:
> > * fixed coding style problems
> > v3 changes:
> > * replaced the numeric by macro
> > ---
> > ---
> > test/test/test_alarm.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/test/test/test_alarm.c b/test/test/test_alarm.c index
> > ecb2f6d..40f55b5 100644
> > --- a/test/test/test_alarm.c
> > +++ b/test/test/test_alarm.c
> > @@ -47,6 +47,7 @@
> >
> > #define RTE_TEST_ALARM_TIMEOUT 10 /* ms */
> > #define RTE_TEST_CHECK_PERIOD 3 /* ms */
> > +#define RTE_TEST_MAX_REPEAT20
> >
> > static volatile int flag;
> >
> > @@ -96,6 +97,7 @@ static int
> > test_multi_alarms(void)
> > {
> > int rm_count = 0;
> > + int count = 0;
> > cb_count.cnt = 0;
> >
> > printf("Expect 6 callbacks in order...\n"); @@ -169,7 +171,10 @@
> > test_multi_alarms(void)
> > printf("Error, cancelling head-of-list leads to premature
> > callback\n");
> > return -1;
> > }
> > - rte_delay_ms(10);
> > +
> > + while (flag != 2 && count++ < RTE_TEST_MAX_REPEAT)
> > + rte_delay_ms(10);
> > +
> > if (flag != 2) {
> > printf("Error - expected callback not called\n");
> > rte_eal_alarm_cancel(test_remove_in_callback, (void *)-1);
> @@
> > -212,7 +217,7 @@ test_alarm(void)
> > printf("fail to set alarm callback\n");
> > return -1;
> > }
> > - while (flag == 0 && count ++ < 6)
> > + while (flag == 0 && count++ < RTE_TEST_MAX_REPEAT)
> > rte_delay_ms(RTE_TEST_CHECK_PERIOD);
> >
> > if (flag == 0){
> > --
> > 2.7.4
Acked-by : Jing Chen
Re: [dpdk-dev] [PATCH v3] test: add delay time in test alarm
+ while (flag != 2 && count++ < RTE_TEST_MAX_REPEAT)
+ rte_delay_ms(10);
Why you don't replace "2" and "10" with macro?
-Original Message-
From: Yang, Qiming
Sent: Tuesday, June 20, 2017 11:24 AM
To: dev@dpdk.org
Cc: Chen, Jing D ; Wu, Jingjing ;
Yang, Qiming
Subject: [PATCH v3] test: add delay time in test alarm
Because accuracy of timing to the microsecond is not guaranteed in
rte_eal_alarm_set, this function will not be called before the requested time,
but may be called a period of time afterwards which can not be calculated. In
order to ensure test alarm running success, this patch added the delay time
before check the flag.
Signed-off-by: Qiming Yang
---
v2 changes:
* fixed coding style problems
v3 changes:
* replaced the numeric by macro
---
---
test/test/test_alarm.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/test/test/test_alarm.c b/test/test/test_alarm.c index
ecb2f6d..40f55b5 100644
--- a/test/test/test_alarm.c
+++ b/test/test/test_alarm.c
@@ -47,6 +47,7 @@
#define RTE_TEST_ALARM_TIMEOUT 10 /* ms */
#define RTE_TEST_CHECK_PERIOD 3 /* ms */
+#define RTE_TEST_MAX_REPEAT20
static volatile int flag;
@@ -96,6 +97,7 @@ static int
test_multi_alarms(void)
{
int rm_count = 0;
+ int count = 0;
cb_count.cnt = 0;
printf("Expect 6 callbacks in order...\n"); @@ -169,7 +171,10 @@
test_multi_alarms(void)
printf("Error, cancelling head-of-list leads to premature
callback\n");
return -1;
}
- rte_delay_ms(10);
+
+ while (flag != 2 && count++ < RTE_TEST_MAX_REPEAT)
+ rte_delay_ms(10);
+
if (flag != 2) {
printf("Error - expected callback not called\n");
rte_eal_alarm_cancel(test_remove_in_callback, (void *)-1); @@
-212,7 +217,7 @@ test_alarm(void)
printf("fail to set alarm callback\n");
return -1;
}
- while (flag == 0 && count ++ < 6)
+ while (flag == 0 && count++ < RTE_TEST_MAX_REPEAT)
rte_delay_ms(RTE_TEST_CHECK_PERIOD);
if (flag == 0){
--
2.7.4
Re: [dpdk-dev] [PATCH v2] net/fm10k: initialize link status in device start
> -Original Message-
> From: Wang, Xiao W
> Sent: Thursday, June 22, 2017 7:20 PM
> To: Chen, Jing D
> Cc: dev@dpdk.org; sta...@dpdk.org; Wang, Xiao W
> Subject: [PATCH v2] net/fm10k: initialize link status in device start
>
> Fm10k host driver can't manage PHY directly and provides a fake link status by
> always reporting LINK_UP. We should initialize link status in device start,
> otherwise application will get LINK_DOWN status when LSC configured.
>
> Fixes: 9ae6068c86da ("fm10k: add dev start/stop")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiao Wang
> ---
> v2:
> * Rewrite commit message, add information about fm10k PHY.
> * Always do link_update in dev_start.
> ---
> drivers/net/fm10k/fm10k_ethdev.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> b/drivers/net/fm10k/fm10k_ethdev.c
> index 7172a0f..c5c4712 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -84,6 +84,8 @@ static void fm10k_MAC_filter_set(struct rte_eth_dev
> *dev, static void fm10k_set_rx_function(struct rte_eth_dev *dev); static
> void
> fm10k_set_tx_function(struct rte_eth_dev *dev); static int
> fm10k_check_ftag(struct rte_devargs *devargs);
> +static int fm10k_link_update(struct rte_eth_dev *dev,
> + __rte_unused int wait_to_complete);
>
> struct fm10k_xstats_name_off {
> char name[RTE_ETH_XSTATS_NAME_SIZE];
> @@ -1166,6 +1168,8 @@ static inline int fm10k_glort_valid(struct fm10k_hw
> *hw)
> if (!(dev->data->dev_conf.rxmode.mq_mode &
> ETH_MQ_RX_VMDQ_FLAG))
> fm10k_vlan_filter_set(dev, hw->mac.default_vid, true);
>
> + fm10k_link_update(dev, 0);
> +
> return 0;
> }
>
Acked-by : Jing Chen
Re: [dpdk-dev] [PATCH] net/fm10k: initialize link status in device start
Hi,
> -Original Message-
> From: Wang, Xiao W
> Sent: Wednesday, May 31, 2017 7:07 PM
> To: Chen, Jing D
> Cc: dev@dpdk.org; Wang, Xiao W ;
> sta...@dpdk.org
> Subject: [PATCH] net/fm10k: initialize link status in device start
>
> If port LSC interrupt is configured, application will read link status
> directly, so
> driver need to prepare that value in advance.
Fm10k host driver can't manage PHY directly and provide a fake link status,
so it always provide a constant value, whatever lsc is set or not.
I think you need to reorganize the message. :)
>
> Fixes: 9ae6068c86da ("fm10k: add dev start/stop")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiao Wang
> ---
> drivers/net/fm10k/fm10k_ethdev.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> b/drivers/net/fm10k/fm10k_ethdev.c
> index a742eec..54bf10c 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -84,6 +84,8 @@ static void fm10k_MAC_filter_set(struct rte_eth_dev
> *dev, static void fm10k_set_rx_function(struct rte_eth_dev *dev); static
> void fm10k_set_tx_function(struct rte_eth_dev *dev); static int
> fm10k_check_ftag(struct rte_devargs *devargs);
> +static int fm10k_link_update(struct rte_eth_dev *dev,
> + __rte_unused int wait_to_complete);
>
> struct fm10k_xstats_name_off {
> char name[RTE_ETH_XSTATS_NAME_SIZE];
> @@ -1166,6 +1168,9 @@ static inline int fm10k_glort_valid(struct fm10k_hw
> *hw)
> if (!(dev->data->dev_conf.rxmode.mq_mode &
> ETH_MQ_RX_VMDQ_FLAG))
> fm10k_vlan_filter_set(dev, hw->mac.default_vid, true);
>
> + if (dev->data->dev_conf.intr_conf.lsc != 0)
> + fm10k_link_update(dev, 0);
> +
I'll recommend updating link status anyway when port starts, not considering
lsc set status.
> return 0;
> }
>
> --
> 1.8.3.1
Re: [dpdk-dev] SIMD Rx/Tx paths
> 15/05/2017 16:12, Richardson, Bruce: > > From: Yigit, Ferruh > > > On 5/15/2017 2:15 PM, Bruce Richardson wrote: > > > > On Mon, May 15, 2017 at 02:35:55PM +0200, Thomas Monjalon wrote: > > > >> Hi, > > > >> > > > >> I would like to open a discussion about SIMD code in drivers. > > > >> > > > >> I think we should not have different behaviours or features > > > >> capabilities, in the different code paths of a same driver. > > > >> I suggest to consider such differences as exceptions. > > > >> So we should merge features files (i.e. matrix columns), and > > > >> remove these files: > > > >> > > > >> % ls doc/guides/nics/features/*_vec.ini > > > >> > > > >> doc/guides/nics/features/fm10k_vec.ini > > > >> doc/guides/nics/features/fm10k_vf_vec.ini > > > >> doc/guides/nics/features/i40e_vec.ini > > > >> doc/guides/nics/features/i40e_vf_vec.ini > > > >> doc/guides/nics/features/ixgbe_vec.ini > > > >> doc/guides/nics/features/ixgbe_vf_vec.ini > > > >> doc/guides/nics/features/virtio_vec.ini > > > >> > > > >> If a feature is not supported in all code paths of a driver, it > > > >> must be marked as partially (P) supported. > > > >> > > > >> Then the mid-term goal will be to try removing these inconsistencies. > > > >> > > > >> Opinions/comments? > > > > > > > > Yes, there are inconsistencies, but if they are hidden from the > > > > user, e.g. by having the driver select automatically the most > > > > appropriate path, I don't think we should need to mark the support as > "partial". > > > > Instead, it should be marked as being fully supported, but perhaps > > > > with a note indicating that a performance hit may be experienced > > > > due to the code taking a less-optimised driver path. After all, > > > > especially in the TX code path, a lot of the speed-up comes from > > > > not supporting different features, as well as from the > > > > vectorization. In those cases "closing the gap" may mean losing > > > > performance for those who don't want the features, which is not > > > > acceptable. Any feature support we can add, without affecting > performance, should of course be implemented. > > > > > > I mostly agree with Bruce, except for PMD selection the patch > > > automatically. > > > > > > There is a trade off between feature set and performance, scalar > > > driver favors features and vector driver favors performance, I think > > > good to have both. > > > > > > And I agree that feature support should be added to vector drivers > > > as long as it doesn't effect the performance. > > > > > > Related to the driver auto selecting the path, I concern this may > > > confuse the user, because he may end up a situation he doesn't clear > > > about supported features, I am for more explicit way to select the > > > scalar or vector driver. > > > > > > And for merging the features files, most of the items are already > > > same for scalar and vector drivers, so perhaps we can merge files > > > and use different syntax for features that is different for scalar and > > > vector: > > > Ys: Yes Scalar [no vector] > > > Yv: Yes Vector [no scalar] > > > Y: Yes Both > > > Ps: Partially Scalar [no vector] > > > Pv: Partially Vector [no scalar] > > > P: Partially Both > > > YsPv, YvPs > > Please remember that there are different vector code paths (SSE/AVX, NEON, > Altivec). > > > For the table, I don't really mind so much what scheme is agreed. For the > user doing the coding, while I can accept that it might be useful to support > explicitly request a vector or scalar driver, I'd definitely prefer the > default > state to remain auto-selection based on features requested. If a user want > TSO, then pick the best driver path that supports TSO, and don't force the > user to read up on what the different paths are! > > I agree. > If we can be sure what the application needs, we can select the best code > path and mark the feature supported. > But can we be sure of the expectations for every features? > How do we know that the application relies on certain packet types (which > are not recognized by some code paths)? I also agree auto-selection on tx/rx func. User needn't worry about how PMD to satisfy its' requirement, result is more important. Besides that, we should do more work in rx/tx configuration to help PMD better decide the best rx/tx. Pkt_type is a good example. A possible way is to expose all possible PMD offload features into structure rte_eth_rxmode and rte_eth_txmode or a new structure.
Re: [dpdk-dev] [PATCH v2] test: add delay time in test alarm
Hi,
> diff --git a/test/test/test_alarm.c b/test/test/test_alarm.c index
> ecb2f6d..cbae1a0 100644
> --- a/test/test/test_alarm.c
> +++ b/test/test/test_alarm.c
> @@ -96,6 +96,7 @@ static int
> test_multi_alarms(void)
> {
> int rm_count = 0;
> + int count = 0;
> cb_count.cnt = 0;
>
> printf("Expect 6 callbacks in order...\n"); @@ -169,7 +170,10 @@
> test_multi_alarms(void)
> printf("Error, cancelling head-of-list leads to premature
> callback\n");
> return -1;
> }
> - rte_delay_ms(10);
> +
> + while (flag != 2 && count++ < 6)
> + rte_delay_ms(10);
> +
> if (flag != 2) {
> printf("Error - expected callback not called\n");
> rte_eal_alarm_cancel(test_remove_in_callback, (void *)-1);
> @@ -212,7 +216,7 @@ test_alarm(void)
> printf("fail to set alarm callback\n");
> return -1;
> }
> - while (flag == 0 && count ++ < 6)
> + while (flag == 0 && count++ < 20)
> rte_delay_ms(RTE_TEST_CHECK_PERIOD);
>
What's the criteria to delay 20* RTE_TEST_CHECK_PERIOD ms? Add more comments?
> if (flag == 0){
> --
> 2.7.4
Overall comment is to replace numeric with macro.
Re: [dpdk-dev] [PATCH] net/fm10k: fix secondary process crash
> -Original Message-
> From: Wang, Xiao W
> Sent: Tuesday, March 28, 2017 11:59 AM
> To: Chen, Jing D
> Cc: dev@dpdk.org; Wang, Xiao W ;
> sta...@dpdk.org
> Subject: [PATCH] net/fm10k: fix secondary process crash
>
> If the primary process has initialized all the queues to vector pmd mode, the
> secondary process should not use scalar code path, because the per queue
> data structures haven't been prepared for that, e.g. txq->ops is for vector Tx
> rather than scalar Tx.
>
> Fixes: a6ce64a97520 ("fm10k: introduce vector driver")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiao Wang
Acked-by : Jing Chen
Re: [dpdk-dev] [PATCH] net/fm10k: fix secondary process crash
> -Original Message-
> From: Wang, Xiao W
> Sent: Tuesday, March 28, 2017 11:59 AM
> To: Chen, Jing D
> Cc: dev@dpdk.org; Wang, Xiao W ; sta...@dpdk.org
> Subject: [PATCH] net/fm10k: fix secondary process crash
>
> If the primary process has initialized all the queues to vector pmd mode, the
> secondary process should not use scalar code path, because the per queue data
> structures haven't been prepared for that, e.g. txq->ops is for vector Tx
> rather
> than scalar Tx.
>
> Fixes: a6ce64a97520 ("fm10k: introduce vector driver")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiao Wang
> ---
> drivers/net/fm10k/fm10k_ethdev.c | 28 ++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> b/drivers/net/fm10k/fm10k_ethdev.c
> index 388f929..680d617 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -2750,6 +2750,21 @@ static void __attribute__((cold))
> int use_sse = 1;
> uint16_t tx_ftag_en = 0;
>
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> + /* primary process has set the ftag flag and txq_flags */
> + txq = dev->data->tx_queues[0];
> + if (fm10k_tx_vec_condition_check(txq)) {
> + dev->tx_pkt_burst = fm10k_xmit_pkts;
> + dev->tx_pkt_prepare = fm10k_prep_pkts;
> + PMD_INIT_LOG(DEBUG, "Use regular Tx func");
> + } else {
> + PMD_INIT_LOG(DEBUG, "Use vector Tx func");
> + dev->tx_pkt_burst = fm10k_xmit_pkts_vec;
> + dev->tx_pkt_prepare = NULL;
> + }
> + return;
> + }
> +
Why we need to check process type? What would happen if no changes made here?
> if (fm10k_check_ftag(dev->device->devargs))
> tx_ftag_en = 1;
>
> @@ -2810,6 +2825,9 @@ static void __attribute__((cold))
> else
> PMD_INIT_LOG(DEBUG, "Use regular Rx func");
>
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> + return;
> +
> for (i = 0; i < dev->data->nb_rx_queues; i++) {
> struct fm10k_rx_queue *rxq = dev->data->rx_queues[i];
>
> @@ -2856,9 +2874,15 @@ static void __attribute__((cold))
> dev->tx_pkt_burst = &fm10k_xmit_pkts;
> dev->tx_pkt_prepare = &fm10k_prep_pkts;
>
> - /* only initialize in the primary process */
> - if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> + /*
> + * Primary process does the whole initialization, for secondary
> + * processes, we just select the same Rx and Tx function as primary.
> + */
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> + fm10k_set_rx_function(dev);
> + fm10k_set_tx_function(dev);
> return 0;
> + }
>
> rte_eth_copy_pci_info(dev, pdev);
> dev->data->dev_flags |= RTE_ETH_DEV_DETACHABLE;
> --
> 1.8.3.1
Re: [dpdk-dev] i40e SR-IOV with Linux PF
>
> +Cc dev@dpdk.org
>
> 2017-03-13 15:29, Thomas Monjalon:
> > Hi i40e developers,
> >
> > Referring to the VFD discussion, I thought basic behaviours were the
> > same regardless of the PF driver:
> > http://dpdk.org/ml/archives/dev/2016-December/053056.html
> > "
> > > In the meanwhile, we have some test models ongoing to validate
> > > combination of Linux and DPDK drivers for VF and PF.
> > > We'll fully support below 4 cases going forward.
> > > 1. DPDK PF + DPDK VF
> > > 2. DPDK PF + Linux VF
> > > 3. Linux PF + DPDK VF
> > > 4. Linux PF + Linux VF (it's not our scope)
> > [...]
> > > Linux PF + DPDK VF has been tested with 1.0 API long time ago.
> > > There is some test activities ongoing.
> > "
> >
> > I think the Linux PF case is important and deserves more consideration.
> > When looking at the code, specifically i40evf_vlan_offload_set() and
> > i40evf_vlan_pvid_set(), I read this:
> > "
> > /* Linux pf host doesn't support vlan offload yet */
> > if (vf->version_major == I40E_DPDK_VERSION_MAJOR) { "
> >
> > Is there some work in progress on Linux side to get the same behaviour
> > as with a DPDK PF?
> >
> > At least, it must be documented in
> > doc/guides/nics/features/i40e_vf.ini
> > and marked as partially supported (P instead of Y) in
> > doc/guides/nics/i40e.rst
Thanks for pointing it out. We'll sync our code with latest kernel driver and
document and comment properly soon.
Re: [dpdk-dev] [PATCH 6/6] doc: introduction to prgdev
> > > > > > > +Another reason to provide bind/unbind action is programmble > > > > +devices, like FPGA, are not identified driver by 'vendor ID' and > > > > +'device ID', they might not be changed in all the ways, even FPGA > > > > +is fully programmed. So, it depends on internal mechanism of > > > > +FPGA, not 'vendor ID' and 'device ID' to identify proper drivers, > > > > +either a register value or signature, depending on FPGA hardware > > > > +design. In this case, EAL or other bus driver doesn't have the > > > > +capability to identify proper driver for FPGA device. With prgdev > > > > +introduced, while FPGA is always a prgdev, FPGA can use prgdev as > > > > +primary driver, to find proper > > > function driver. > > > > > > You mean prgdev should help the bus layer to map the right driver > interface? > > > It looks weird and dangerous. The standard way to identify a PCI > > > device is to look at its IDs. Other unknown methods must be strongly > discussed. > > > > For programmable Ethernet device, it's not truce. But for FPGA, it's. > > When FPGA is produced, the device ID indicate what model it is and > > won't be changed anyway, even being reprogrammed. It used some > > not-generic mechanism, like AFU id to distinguish the personalities. > > So, for FPGA, a prgdev driver can be used as primary driver to identify > personalities and then register to specific devices. > > Sounds like we would need an FPGA bus driver in that case. I think that would > be a better solution than having a specific device driver loading other > drivers. > I don't object to introduce a pseudo bus for FPGA, but it's a matter of work that FPGA driver needs to consider, not in scope of prgdev. Besides that, I can see DPDK EAL will do other bus probe first, then PCI bus probe, which is not friendly to introduce pseudo bus for an actual PCI device. > /Bruce
Re: [dpdk-dev] [PATCH 6/6] doc: introduction to prgdev
Hi, Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Monday, March 6, 2017 11:27 PM > To: Chen, Jing D > Cc: dev@dpdk.org; Liang, Cunming ; Rogers, > Gerald ; Wiles, Keith ; > Richardson, Bruce ; Mcnamara, John > > Subject: Re: [dpdk-dev] [PATCH 6/6] doc: introduction to prgdev > > 2017-03-02 12:03, Chen Jing D: > > +Overview > > + > > I think the first review pass of this series must be focused on the overview > you give here (thanks for the detailed explanations). > > I'll try to sum up while commenting. > > [...] > The target is programmable devices. > > > +The major purpose of prgdev is to help DPDK users to load/upgrade RTL > > +images for FPGA devices, or upgrade firmware for programmble NICs. > > This is a control plane feature. > You want to have it in DPDK to allow dynamic programmation while running > the device, right? Exactly right. > > [...] > > +When the set of APIs is introduced, a general question is why we need > > +it in DPDK community? > > Good question :) > > [...] > > +Any devices, having the capability to store/load a piece of info > > +to/from the deivce then changed hardware behavior, and applicable to > > +prgdev programming model, could be registered as a prgdev device. > > + > > +The device can be programmed (dynamic) within DPDK or have been prior > > +programmed > > +(static) prior to a DPDK application being launched. > [...] > > +Besides the simple API to upload/download image, the prgdev also > > +introduces a mechanism internally to switch drivers and > > +register/unregister device on the fly. With this mechanism, apps can > > +use the programmable device, unbind other personalities on demand, > then program it and bind it back with new personalities. > > +Apps can follow below examples to simply complete the whole process. > > I disagree about the specific bind/unbind for prgdev. > We must improve binding inside DPDK for every devices. First of all, let us try to imagine what is the safe status for device before apps intending to download some image to it - apps wouldn't operate on the device, any behaviors like configuring registers, receive/transmit data may impair the device or make the download failed. Following first answer to prevent app accessing device during image downloading, how can we achieve that? Detach drivers with device is a smart idea, right? But the problem is how can apps use prgdev API to download image after all drivers detached with the device? So, the final question is how can we just detached others driver except prgdev one? I can't find answer in current DPDK framework, that's why I'd like to introduce bind/unbind functions to detach other drivers from the device. I'm open to this problem. If any suggestion or mechanism can help on it, I can remove these 2. BTW, not all devices or image download actions need the device to detach the device, depending on hardware implementation. > > > +Note that bind/unbind actions are different concept from that a whole > > +device attach/detach. For example, ``rte_eal_dev_detach()``, which > > +will try to detach the drivers with device and remove the whole > > +device from specific class of devices (ethdev, for example). Then, the > whole device is invisible until a new 'probe' > > +is activated. > > I do not understand. See above explanations. > > > +During the whole procedure of image upload/download, prgdev handler > > +is always valid and apps can use it operate on programmable device. > > +The reason why unbind is necessary is it may break the hardware when > > +programming is in progress while other functions are active. Using > > +programmble NIC as an example, it's a little impossible to > > +receive/forward packets for hardware while updating firmware. In this > > +case, apps need to detach ethdev function before firmware upgrading. > > +Again, prgdev handler is still valid, it's function-level detach, > > +different from device-level detach. After finishing image download, > > +original function needs to attach back, either use same or different > > +drivers, depends on personalities changed or not. For a programmble NIC, > the driver may be the same. For FPGA, it may not, see below examples to get > more details. > > If the personality of the device is changed, it must be seen as a new device > from e.g. the ethdev point of view, while keeping the same prgdev device. > In other words, a device can have several interfaces at the same time (ethdev, > cryptodev, eventdev, prgdev, whatever). > I think we can dynamicall
[dpdk-dev] [PATCH 5/6] prgdev: add ABI control info
Add rte_prgdev_version.map file.
Signed-off-by: Chen Jing D(Mark)
Signed-off-by: Gerald Rogers
---
lib/librte_prgdev/rte_prgdev_version.map | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 lib/librte_prgdev/rte_prgdev_version.map
diff --git a/lib/librte_prgdev/rte_prgdev_version.map
b/lib/librte_prgdev/rte_prgdev_version.map
new file mode 100644
index 000..51dc15a
--- /dev/null
+++ b/lib/librte_prgdev/rte_prgdev_version.map
@@ -0,0 +1,19 @@
+DPDK_17.05 {
+ global:
+
+ rte_prgdev_pci_probe;
+ rte_prgdev_pci_remove;
+ rte_prgdev_allocate;
+ rte_prgdev_release;
+ rte_prgdev_info_get;
+ rte_prgdev_is_valid_dev;
+ rte_prgdev_open;
+ rte_prgdev_img_download;
+ rte_prgdev_img_upload;
+ rte_prgdev_check_stat;
+ rte_prgdev_close;
+ rte_prgdev_bind;
+ rte_prgdev_unbind;
+
+ local: *;
+};
--
1.7.7.6
[dpdk-dev] [PATCH 4/6] prgdev: add prgdev API exposed to application
Add a series of API and implementations that application can
operate on a programmble device. The major functions are download
and upload an image to/from device.
Signed-off-by: Chen Jing D(Mark)
Signed-off-by: Gerald Rogers
---
lib/librte_prgdev/rte_prgdev.c | 226
lib/librte_prgdev/rte_prgdev.h | 106 +++
2 files changed, 332 insertions(+), 0 deletions(-)
diff --git a/lib/librte_prgdev/rte_prgdev.c b/lib/librte_prgdev/rte_prgdev.c
index 03465f9..558e97b 100644
--- a/lib/librte_prgdev/rte_prgdev.c
+++ b/lib/librte_prgdev/rte_prgdev.c
@@ -231,3 +231,229 @@ struct rte_prgdev *
return 0;
}
+int
+rte_prgdev_is_valid_dev(uint8_t dev_id)
+{
+ /* Not support secondary process to operate on prgdev */
+ RTE_PRG_PRIMARY_PROC_OR_ERR_RET(-EINVAL);
+ RTE_PRG_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+
+ if (dev_id >= RTE_PRGDEV_MAX_DEVS ||
+ rte_prgdev_devices[dev_id].attached != PRGDEV_ATTACHED)
+ return 0;
+ else
+ return 1;
+}
+
+uint8_t
+rte_prgdev_count(void)
+{
+ /* Not support secondary process to operate on prgdev */
+ RTE_PRG_PRIMARY_PROC_OR_ERR_RET(-EINVAL);
+
+ return nb_devs;
+}
+
+static inline int
+prgdev_devid_check(uint8_t dev_id, struct rte_prgdev **dev)
+{
+ /* Not support secondary process to operate on prgdev */
+ RTE_PRG_PRIMARY_PROC_OR_ERR_RET(-EINVAL);
+ RTE_PRG_VALID_DEVID_OR_ERR_RET(dev_id, -EINVAL);
+
+ if (dev_id >= nb_devs) {
+ PRG_LOG_ERR("Invalid dev_id=%d", dev_id);
+ return -EINVAL;
+ }
+
+ *dev = &rte_prgdev_devices[dev_id];
+ return 0;
+}
+
+int
+rte_prgdev_info_get(uint8_t dev_id,
+ struct rte_prgdev_info *info)
+{
+ struct rte_prgdev *dev;
+ int ret;
+
+ ret = prgdev_devid_check(dev_id, &dev);
+ if (ret)
+ return ret;
+
+ memset(info, 0, sizeof(*info));
+
+ RTE_PRG_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->prg_infos_get, -ENOTSUP);
+ (*dev->dev_ops->prg_infos_get)(dev, info);
+
+ info->pci_dev = RTE_DEV_TO_PCI(dev->device);
+ if (dev->driver)
+ info->driver_name = dev->driver->pci_drv.driver.name;
+ return 0;
+}
+
+int
+rte_prgdev_open(uint8_t dev_id)
+{
+ struct rte_prgdev *dev;
+ struct rte_prgdev_info dev_info;
+ int ret;
+
+ ret = prgdev_devid_check(dev_id, &dev);
+ if (ret)
+ return ret;
+
+ RTE_PRG_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->prg_infos_get, -ENOTSUP);
+ RTE_PRG_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->prg_open, -ENOTSUP);
+
+ (*dev->dev_ops->prg_infos_get)(dev, &dev_info);
+
+ if (dev_info.status != RTE_PRG_STAT_READY)
+ return -1;
+
+ return (*dev->dev_ops->prg_open)(dev);
+}
+
+int
+rte_prgdev_img_download(uint8_t dev_id,
+ uint8_t *buffer_ptr, uint32_t buf_len)
+{
+ struct rte_prgdev *dev;
+ struct rte_prgdev_info dev_info;
+ int ret;
+
+ ret = prgdev_devid_check(dev_id, &dev);
+ if (ret)
+ return ret;
+
+ if (buffer_ptr == NULL || buf_len == 0)
+ return -EINVAL;
+
+ RTE_PRG_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->prg_download, -ENOTSUP);
+ RTE_PRG_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->prg_infos_get, -ENOTSUP);
+
+ (*dev->dev_ops->prg_infos_get)(dev, &dev_info);
+
+ if (dev_info.status != RTE_PRG_STAT_OPEN)
+ return -1;
+
+ return (*dev->dev_ops->prg_download)(dev, buffer_ptr, buf_len);
+}
+
+int
+rte_prgdev_img_upload(uint8_t dev_id, uint8_t *buffer_ptr,
+ uint32_t buf_len, uint32_t *act_len)
+{
+ struct rte_prgdev *dev;
+ struct rte_prgdev_info dev_info;
+ int ret;
+
+ ret = prgdev_devid_check(dev_id, &dev);
+ if (ret)
+ return ret;
+
+ if (buffer_ptr == NULL || buf_len == 0 || act_len == NULL)
+ return -EINVAL;
+
+ RTE_PRG_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->prg_upload, -ENOTSUP);
+ RTE_PRG_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->prg_infos_get, -ENOTSUP);
+
+ (*dev->dev_ops->prg_infos_get)(dev, &dev_info);
+
+ if (dev_info.status != RTE_PRG_STAT_OPEN)
+ return -1;
+
+ return (*dev->dev_ops->prg_upload)(dev, buffer_ptr, buf_len, act_len);
+}
+
+int
+rte_prgdev_check_stat(uint8_t dev_id, enum rte_prg_fwstat *stat)
+{
+ struct rte_prgdev *dev;
+ struct rte_prgdev_info dev_info;
+ int ret;
+
+ ret = prgdev_devid_check(dev_id, &dev);
+ if (ret)
+ return ret;
+
+ RTE_PRG_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->prg_check_stat, -ENOTSUP);
+ RTE_PRG_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->prg_infos_get, -ENOTSUP);
+
[dpdk-dev] [PATCH 6/6] doc: introduction to prgdev
From: "Chen, Jing D" This is the documentation to describe what prgdev is, how to use prgdev API and accomplish an image download. Signed-off-by: Chen Jing D(Mark) Signed-off-by: Gerald Rogers Signed-off-by: John Mcnamara --- doc/guides/prog_guide/index.rst |1 + doc/guides/prog_guide/prgdev_lib.rst | 465 ++ 2 files changed, 466 insertions(+), 0 deletions(-) create mode 100644 doc/guides/prog_guide/prgdev_lib.rst diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst index 77f427e..4a24264 100644 --- a/doc/guides/prog_guide/index.rst +++ b/doc/guides/prog_guide/index.rst @@ -60,6 +60,7 @@ Programmer's Guide qos_framework power_man packet_classif_access_ctrl +prgdev_lib packet_framework vhost_lib port_hotplug_framework diff --git a/doc/guides/prog_guide/prgdev_lib.rst b/doc/guides/prog_guide/prgdev_lib.rst new file mode 100644 index 000..e2d1e2e --- /dev/null +++ b/doc/guides/prog_guide/prgdev_lib.rst @@ -0,0 +1,465 @@ +Overview + + +More and more devices start to support on-die programming, which include +NIC, GPU, FPGA, etc. This capability has a requirement to drivers that +introduce a API for application to download/upload image to/from the HW. +So, it's necessary to provide a generic API to perform image download, upload, +validation, etc. + +This RFC patch intends to introduce a DPDK generic programming device layer, +called prgdev below, to provide an abstract, generic APIs for applications to +program hardware without knowing the details of programmable devices. From +driver's perspective, they'll try to adapt their functions to the abstract +APIs defined in prgdev. + +The major purpose of prgdev is to help DPDK users to load/upgrade RTL images +for FPGA devices, or upgrade firmware for programmble NICs. + +But those devices that have the capability to do on-die programming may +expose versatile talents to apps. Add/delete/update entries in flow table, +update/overwrite the firmware/microcode, add a new algorithm, update profiles, +etc, which is hard to be abstracted as generic behaviors. So, prgdev won't +include the APIs to perform device-unique actions in current stage until it +became popular. On the contratry, it only provides the simple capability to +download a segment of buffer(image) from host to on-die device, or vice versa. +The image could be an algorithm, a flow table in the on-die SRAM, a firmware +image running in the device, a function within a pipeline, etc. prgdev won't +try to inteprete the content and it's transparent to prgdev. Apps and devices +can communicate with a language they can understand each other, which is not +provided by prgdev to decide what needs to be programmed. + +When the set of APIs is introduced, a general question is why we need it in +DPDK community? Why we can't use offline tool to perform same thing? The answer +is the prgdev provide a generic, online API to applications, in the meanwile, +offers a capability to switch driver dynamically when downloaded image changed +personality and a new driver is required. Comparing offline tool, it have online +programmability (see below examples); Comparing online tool, it provides a +generic API for many HWs; Comparing generic online tool/API for many products, +it provides a capability to switch driver dynamically. + +There are various means to reach same goal, we'll try to find the best/better +way to approach. All above advantages will help prgdev to be a 'better choice'. + + +Scope +- + +The target devices include but not limited to programmable NIC, FPGA, GPU. +Any devices, having the capability to store/load a piece of info to/from +the deivce then changed hardware behavior, and applicable to prgdev programming +model, could be registered as a prgdev device. + +The device can be programmed (dynamic) within DPDK or have been prior programmed +(static) prior to a DPDK application being launched. + +Static example: In a static example a program, bitstream or other firmware +would have been loaded prior to the start of a DPDK application. The prgdev +would recognize the firmware loaded, and instantiate higher level interfaces +(example : PMD, L3 forwarding, flow, etc.). + +Dynamic example: In a dynamic example, the programmability of the program, +bitstream or other firmware would be loaded by the DPDK application upon start +, or during execution. The prgdev would offer the interface to allow the DPDK +application to program the device. + + +Dyanamic bind/unbind + + +Besides the simple API to upload/download image, the prgdev also introduces a +mechanism internally to switch drivers and register/unregister device on the +fly. With this mechanism, apps can use the programmable device, unbind other +personalities on demand, then program it and bind it back with new personalities. +Apps can follow below
[dpdk-dev] [PATCH 2/6] prgdev: add debug macro for prgdev
Add debug macro in rte_log.h to support prgdev.
Add debug message macro for debugging.
Signed-off-by: Chen Jing D(Mark)
Signed-off-by: Gerald Rogers
---
lib/librte_eal/common/include/rte_log.h |1 +
lib/librte_prgdev/rte_prgdev.h | 67 +++
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_log.h
b/lib/librte_eal/common/include/rte_log.h
index 954b96c..7422962 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -80,6 +80,7 @@ struct rte_logs {
#define RTE_LOGTYPE_MBUF0x0001 /**< Log related to mbuf. */
#define RTE_LOGTYPE_CRYPTODEV 0x0002 /**< Log related to cryptodev. */
#define RTE_LOGTYPE_EFD 0x0004 /**< Log related to EFD. */
+#define RTE_LOGTYPE_PRG0x0008 /**< Log related to prg device. */
/* these log types can be used in an application */
#define RTE_LOGTYPE_USER1 0x0100 /**< User-defined log type 1. */
diff --git a/lib/librte_prgdev/rte_prgdev.h b/lib/librte_prgdev/rte_prgdev.h
index e69de29..52f8a45 100644
--- a/lib/librte_prgdev/rte_prgdev.h
+++ b/lib/librte_prgdev/rte_prgdev.h
@@ -0,0 +1,67 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016-2017 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_PRGDEV_H_
+#define _RTE_PRGDEV_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+/* Logging Macros */
+#define PRG_LOG_ERR(...) \
+ RTE_LOG(ERR, PRG, \
+ RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+ __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))
+
+#ifdef RTE_LIBRTE_PRGDEV_DEBUG
+#define PRG_LOG_DEBUG(...) \
+ RTE_LOG(DEBUG, PRG, \
+ RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+ __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))
+#else
+#define PRG_LOG_DEBUG(...) (void)0
+#endif
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_PRGDEV_H_ */
--
1.7.7.6
[dpdk-dev] [PATCH 3/6] prgdev: add bus probe and remove functions
This patch adds 4 major functions: pci_probe/pci_remove,
prgdev_allocate/prgdev_release to help drivers registering
programmable devices.
pci_probe functions helps drivers to allocate prgdev structures
and trigger an initialization function that drivers provided.
This function will be called when bus scan action performed or
hotplug occured.
prgdev_allocate will allocate a prgdev structures, but won't
perform an intialization of the device. Comparing pci_probe
function which will be triggered by bus scan, it can be called
at any time by driver.
Signed-off-by: Chen Jing D(Mark)
Signed-off-by: Gerald Rogers
---
lib/librte_prgdev/rte_prgdev.c | 233
lib/librte_prgdev/rte_prgdev.h | 228 +++
2 files changed, 461 insertions(+), 0 deletions(-)
diff --git a/lib/librte_prgdev/rte_prgdev.c b/lib/librte_prgdev/rte_prgdev.c
index e69de29..03465f9 100644
--- a/lib/librte_prgdev/rte_prgdev.c
+++ b/lib/librte_prgdev/rte_prgdev.c
@@ -0,0 +1,233 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016-2017 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rte_prgdev.h"
+
+static struct rte_prgdev rte_prgdev_devices[RTE_PRGDEV_MAX_DEVS];
+static uint8_t nb_devs;
+
+static struct rte_prgdev *rte_prgdev_allocated(char *name);
+
+int
+rte_prgdev_pci_probe(struct rte_pci_driver *pci_drv,
+ struct rte_pci_device *pci_dev)
+{
+ struct prgdev_driver *prgdrv;
+ struct rte_prgdev *prgdev;
+ char prgdev_name[PRGDEV_NAME_MAX_LEN];
+ int retval;
+
+ /* Not support secondary process to operate on prgdev */
+ RTE_PRG_PRIMARY_PROC_OR_ERR_RET(-EINVAL);
+
+ prgdrv = (struct prgdev_driver *)pci_drv;
+ if (prgdrv == NULL)
+ return -ENODEV;
+
+ rte_eal_pci_device_name(&pci_dev->addr, prgdev_name,
+ sizeof(prgdev_name));
+
+ prgdev = rte_prgdev_allocate(prgdev_name);
+ if (prgdev == NULL)
+ return -1;
+
+ prgdev->dev_data.dev_private =
+ rte_zmalloc_socket(
+ "prgdevprivate structure",
+ prgdrv->dev_private_size,
+ RTE_CACHE_LINE_SIZE,
+ rte_socket_id());
+
+ if (prgdev->dev_data.dev_private == NULL)
+ rte_panic("Cannot allocate memzone for private "
+ "device data");
+
+ prgdev->device = &pci_dev->device;
+ prgdev->driver = prgdrv;
+
+
+ /* Invoke PMD device initialization function */
+ retval = (*prgdrv->prgdev_init)(prgdev);
+ if (retval == 0)
+ return 0;
+
+ PRG_LOG_ERR("driver %s: prgdev_init(vendor_id=0x%x device_id=0x%x)"
+ " failed", pci_drv->driver.name,
+ (unsigned) pci_dev->id.vendor_id,
+ (unsign
[dpdk-dev] [PATCH 1/6] prgdev: introduce new library
Change configuration files, add new library prgdev into compile system. Signed-off-by: Chen Jing D(Mark) Signed-off-by: Gerald Rogers --- config/common_base |7 + lib/Makefile |1 + lib/librte_prgdev/Makefile | 57 mk/rte.app.mk |1 + 4 files changed, 66 insertions(+), 0 deletions(-) create mode 100644 lib/librte_prgdev/Makefile create mode 100644 lib/librte_prgdev/rte_prgdev.c create mode 100644 lib/librte_prgdev/rte_prgdev.h diff --git a/config/common_base b/config/common_base index aeee13e..71e 100644 --- a/config/common_base +++ b/config/common_base @@ -377,6 +377,13 @@ CONFIG_RTE_CRYPTO_MAX_DEVS=64 CONFIG_RTE_CRYPTODEV_NAME_LEN=64 # +# Compile generic prgdev device library +# +CONFIG_RTE_LIBRTE_PRGDEV=y +CONFIG_RTE_LIBRTE_PRGDEV_DEBUG=n +CONFIG_RTE_PRGDEV_MAX_DEVS=128 + +# # Compile PMD for ARMv8 Crypto device # CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO=n diff --git a/lib/Makefile b/lib/Makefile index 4178325..5c62944 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -59,6 +59,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_TABLE) += librte_table DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += librte_pipeline DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += librte_pdump +DIRS-$(CONFIG_RTE_LIBRTE_PRGDEV) += librte_prgdev ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni diff --git a/lib/librte_prgdev/Makefile b/lib/librte_prgdev/Makefile new file mode 100644 index 000..2c7e179 --- /dev/null +++ b/lib/librte_prgdev/Makefile @@ -0,0 +1,57 @@ +# BSD LICENSE +# +# Copyright(c) 2016-2017 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +include $(RTE_SDK)/mk/rte.vars.mk + +# +# library name +# +LIB = librte_prgdev.a + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +EXPORT_MAP := rte_prgdev_version.map + +LIBABIVER := 3 + +# +# all source are stored in SRCS-y +# +SRCS-$(CONFIG_RTE_LIBRTE_PIPELINE) := rte_prgdev.c + +# install includes +SYMLINK-$(CONFIG_RTE_LIBRTE_PIPELINE)-include += rte_prgdev.h + +# this lib depends upon: +DEPDIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += lib/librte_eal + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_prgdev/rte_prgdev.c b/lib/librte_prgdev/rte_prgdev.c new file mode 100644 index 000..e69de29 diff --git a/lib/librte_prgdev/rte_prgdev.h b/lib/librte_prgdev/rte_prgdev.h new file mode 100644 index 000..e69de29 diff --git a/mk/rte.app.mk b/mk/rte.app.mk index d46a33e..79ab842 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -99,6 +99,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_RING) += -lrte_ring _LDLIBS-$(CONFIG_RTE_LIBRTE_EAL)+= -lrte_eal _LDLIBS-$(CONFIG_RTE_LIBRTE_CMDLINE)+= -lrte_cmdline _LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER)+= -lrte_reorder +_LDLIBS-$(CONFIG_RTE_LIBRTE_PRGDEV) += -lrte_prgdev ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n) # plugins (link only if static libraries) -- 1.7.7.6
[dpdk-dev] [PATCH 0/6] introduce prgdev abstraction library
These patch set intend to introduce a DPDK generic programming device layer, called prgdev, to provide an abstract, generic APIs for applications to program hardware without knowing the details of programmable devices. From driver's perspective, they'll try to adapt their functions to the abstract APIs defined in prgdev. The major purpose of prgdev is to help DPDK users to dynamically load/upgrade RTL images for FPGA devices, or upgrade firmware for programmble NICs, without breaking DPDK application running. Chen Jing D(Mark) (5): prgdev: introduce new library prgdev: add debug macro for prgdev prgdev: add bus probe and remove functions prgdev: add prgdev API exposed to application prgdev: add ABI control info Chen, Jing D (1): doc: introduction to prgdev config/common_base |7 + doc/guides/prog_guide/index.rst |1 + doc/guides/prog_guide/prgdev_lib.rst | 465 ++ lib/Makefile |1 + lib/librte_eal/common/include/rte_log.h |1 + lib/librte_prgdev/Makefile | 57 lib/librte_prgdev/rte_prgdev.c | 459 + lib/librte_prgdev/rte_prgdev.h | 401 ++ lib/librte_prgdev/rte_prgdev_version.map | 19 ++ mk/rte.app.mk|1 + 10 files changed, 1412 insertions(+), 0 deletions(-) create mode 100644 doc/guides/prog_guide/prgdev_lib.rst create mode 100644 lib/librte_prgdev/Makefile create mode 100644 lib/librte_prgdev/rte_prgdev.c create mode 100644 lib/librte_prgdev/rte_prgdev.h create mode 100644 lib/librte_prgdev/rte_prgdev_version.map -- 1.7.7.6
Re: [dpdk-dev] [RFC 2/2] prgdev: introduce generic prgdev API
Hi, Keith, Stephen,
> -Original Message-
> From: Wiles, Keith
> Sent: Thursday, February 9, 2017 7:07 AM
> To: Stephen Hemminger
> Cc: Chen, Jing D ; dev@dpdk.org; Rogers, Gerald
>
> Subject: Re: [dpdk-dev] [RFC 2/2] prgdev: introduce generic prgdev API
>
>
> > On Feb 8, 2017, at 4:49 PM, Stephen Hemminger
> wrote:
> >
> > On Fri, 20 Jan 2017 11:21:38 +0800
> > "Chen Jing D(Mark)" wrote:
> >
> >> +struct rte_prg_dev_info {
> >> + struct rte_pci_device *pci_dev; /**< Device PCI information. */
> >
> > NAK
> >
> > No new API should refer to PCI devices. We are trying to make all
> > references to devices generic. Crypto suceeded, ether is in process, but no
> new ones please.
>
> The design is not PCI centric and should not be PCI centric, it is just what
> they
> started with months ago. So please look past the PCI bits as they have not
> integrated into the latest code base yet.
>
I got you. Will remove the reference in formal patch.
Re: [dpdk-dev] [RFC 1/2] doc: introduction to prgdev
Hi, Jan, On 2/1/2017 7:41 PM, Jan Blunck wrote: On Fri, Jan 20, 2017 at 4:21 AM, Chen Jing D(Mark) wrote: This is the documentation to describe what prgdev is, how to use prgdev API and accomplish an image download. Signed-off-by: Chen Jing D(Mark) --- doc/guides/prog_guide/prgdev_lib.rst | 457 ++ 1 files changed, 457 insertions(+), 0 deletions(-) create mode 100644 doc/guides/prog_guide/prgdev_lib.rst diff --git a/doc/guides/prog_guide/prgdev_lib.rst b/doc/guides/prog_guide/prgdev_lib.rst new file mode 100644 index 000..3917c18 --- /dev/null +++ b/doc/guides/prog_guide/prgdev_lib.rst @@ -0,0 +1,457 @@ +Overview + + +More and more devices start to support on-die programming, which include +NIC, GPU, FPGA, etc. This capability has a requirement to drivers that +introduce a API for application to download/upload image to/from the HW. +So, it's necessary to provide a generic API to perform image download, upload, +validation, etc. + +This RFC patch intends to introduce a DPDK generic programming device layer, +called prgdev below, to provide an abstract, generic APIs for applications to +program hardware without knowing the details of programmable devices. From +driver's perspective, they'll try to adapt their functions to the abstract +APIs defined in prgdev. + +The major purpose of prgdev is to help DPDK users to load/upgrade RTL images +for FPGA devices, or upgrade firmware for programmble NICs. + +But those devices that have the capability to do on-die programming may +expose versatile talents to apps. Add/delete/update entries in flow table, +update/overwrite the firmware/microcode, add a new algorithm, update profiles +, etc, which is hard to be abstracted as generic behaviors. So, prgdev won't +include the APIs to perform device-unique actions in current stage until it +became popular. On the contratry, it only provides the simple capability to +download a segment of buffer(image) from host to on-die device, or vice versa. +The image could be an algorithm, a flow table in the on-die SRAM, a firmware +image running in the device, a function within a pipeline, etc. prgdev won't +try to inteprete the content and it's transparent to prgdev. Apps and devices +can communicate with a language they can understand each other, which is not +provided by prgdev to decide what needs to be programmed. + +When the set of APIs is introduced, a general question is why we need it in +DPDK community? Why we can't use offline tool to perform same thing? The answer +is the prgdev provide a generic, online API to applications, in the meanwile, +offers a capability to switch driver dynamically when downloaded image changed +personality and a new driver is required. Comparing offline tool, it have online +programmability (see below examples); Comparing online tool, it provides a +generic API for many HWs; Comparing generic online tool/API for many products, +it provides a capability to switch driver dynamically. + +There are various means to reach same goal, we'll try to find the best/better +way to approach. All above advantages will help prgdev to be a 'better choice'. + From my point of view this doesn't belong into the DPDK. On Linux this is traditionally handled by udev and you already have the freedom to use userspace applications to program a device requiring firmware in that case. I don't believe that modeling this in the DPDK explicitly is the right thing to do. Can you kindly educate me what udev can do? It's for NIC firmware upgrade? This prgdev is not only for NIC, the major use case is FPGA, but I found programmable NIC is also applicable to the API model and can be added into the scope. Especially if the device supports changing personality it is required to unplug the existing personality before reprogramming. You can do this already today. Also writing OOB firmware data that changes configuration should be possible today by handling interrupts. What if application is using DPDK, can we do in the same manner without leaving DPDK instance? Maybe we can come up with an example application that demonstrates how the different infrastructure components could get orchestrated. Do you have a device in mind that supports this? As Cunming suggested, the incoming FPGA is the desired device to use this API. OVS that is using DPDK can benefit from the API and download personalities in running time for blank FPGA, or upgrade for prior-programmed case. Regards, Jan
[dpdk-dev] [RFC 2/2] prgdev: introduce generic prgdev API
A new file to define prgdev API prototype and corresponding data
structures.
Signed-off-by: Chen Jing D(Mark)
---
lib/librte_prgdev/rte_prgdev.h | 242
1 files changed, 242 insertions(+), 0 deletions(-)
create mode 100644 lib/librte_prgdev/rte_prgdev.h
diff --git a/lib/librte_prgdev/rte_prgdev.h b/lib/librte_prgdev/rte_prgdev.h
new file mode 100644
index 000..849aba4
--- /dev/null
+++ b/lib/librte_prgdev/rte_prgdev.h
@@ -0,0 +1,242 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016-2017 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_PRGDEV_H_
+#define _RTE_PRGDEV_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*
+ * reflect the device status
+ */
+enum rte_prg_devstat {
+ RTE_PRGDEV_STAT_UNKNOWN = 0, /** Device in a unkown state */
+ RTE_PRGDEV_STAT_READY, /** Device is ready to be programming. */
+ RTE_PRGDEV_STAT_ERASING, /** Device is ready being programmed. */
+ /** Device is performing functionalities and can't be programmed. */
+ RTE_PRGDEV_STAT_RUNNING,
+};
+
+/* Reflect the function block attributes */
+/* Block is readable */
+#define RTE_PGR_FUNC_ATTR_RD 0x0001
+/* Block is writable */
+#define RTE_PGR_FUNC_ATTR_WR 0x0002
+/* Block is readable and writable */
+#define RTE_PGR_FUNC_ATTR_RDWR (RTE_PGR_FUNC_ATTR_RD & RTE_PGR_FUNC_ATTR_WR)
+
+struct rte_prg_blk_info {
+ unsigned int size; /* the block size in bytes */
+ unsigned int version; /* It's optional */
+ unsigned int flags;/* Flags to indicate block isreadable/writable */
+};
+
+#define MAX_SIGNATURE_LEN 256
+#define MAX_BLK_NUM256
+
+struct rte_prg_dev_info {
+ struct rte_pci_device *pci_dev; /**< Device PCI information. */
+ const char *driver_name; /**< Device Driver name. */
+ unsigned int devid; /**< Index to bound host interface, or 0 if none. */
+ /* Programable device HW version number. it's possible that app
+* have dependency to HW version.
+*/
+ uint16_t hw_ver_major; /* major version number */
+ uint16_t hw_ver_minor; /* minor version number */
+
+ /* A array to store hardware, firmware, running image info.Each device
+* can define and interpret the info. For example, a device can define
+* byte[3:0] as signature for on-die personality, byte[5:4] is the major
+* version, byte[7:6] is minor version. if 0xFFEA1000 is a signature for
+* virtio personality, major version is 0x0001, minor version is 0x0004.
+* then signature can be defined :
+* sig_num = 8;
+* signature[7:0]= {00, 0x10, 0xEA, 0xFF, 0x00, 0x01, 0x00, 0x04};
+*/
+ unsigned int sig_num; /** < the valid signature length in bytes> */
+ char signature[MAX_SIGNATURE_LEN];
+ enum rte_prg_devstat status;
+
+ /* number of blocks within device */
+ unsigned int blk_num;
+ /* block info */
+ struct rte_prg_blk_info blk_info[MAX_BLK_NUM];
+};
+
+struct rte_prg_dev {
+struct rte_prg_dev_info prg_dev_info;
+} __rte_cache_aligned;
+
+/*
+* prg_dev_init routine
+*
+* returns : 0 success, non zero failure.
+*/
+
+typedef int (*prg_dev_init_t)(struct rte_prg_dev *prg_dev);
+
+/*
+* prg_dev_
[dpdk-dev] [RFC 1/2] doc: introduction to prgdev
This is the documentation to describe what prgdev is, how to use prgdev API and accomplish an image download. Signed-off-by: Chen Jing D(Mark) --- doc/guides/prog_guide/prgdev_lib.rst | 457 ++ 1 files changed, 457 insertions(+), 0 deletions(-) create mode 100644 doc/guides/prog_guide/prgdev_lib.rst diff --git a/doc/guides/prog_guide/prgdev_lib.rst b/doc/guides/prog_guide/prgdev_lib.rst new file mode 100644 index 000..3917c18 --- /dev/null +++ b/doc/guides/prog_guide/prgdev_lib.rst @@ -0,0 +1,457 @@ +Overview + + +More and more devices start to support on-die programming, which include +NIC, GPU, FPGA, etc. This capability has a requirement to drivers that +introduce a API for application to download/upload image to/from the HW. +So, it's necessary to provide a generic API to perform image download, upload, +validation, etc. + +This RFC patch intends to introduce a DPDK generic programming device layer, +called prgdev below, to provide an abstract, generic APIs for applications to +program hardware without knowing the details of programmable devices. From +driver's perspective, they'll try to adapt their functions to the abstract +APIs defined in prgdev. + +The major purpose of prgdev is to help DPDK users to load/upgrade RTL images +for FPGA devices, or upgrade firmware for programmble NICs. + +But those devices that have the capability to do on-die programming may +expose versatile talents to apps. Add/delete/update entries in flow table, +update/overwrite the firmware/microcode, add a new algorithm, update profiles +, etc, which is hard to be abstracted as generic behaviors. So, prgdev won't +include the APIs to perform device-unique actions in current stage until it +became popular. On the contratry, it only provides the simple capability to +download a segment of buffer(image) from host to on-die device, or vice versa. +The image could be an algorithm, a flow table in the on-die SRAM, a firmware +image running in the device, a function within a pipeline, etc. prgdev won't +try to inteprete the content and it's transparent to prgdev. Apps and devices +can communicate with a language they can understand each other, which is not +provided by prgdev to decide what needs to be programmed. + +When the set of APIs is introduced, a general question is why we need it in +DPDK community? Why we can't use offline tool to perform same thing? The answer +is the prgdev provide a generic, online API to applications, in the meanwile, +offers a capability to switch driver dynamically when downloaded image changed +personality and a new driver is required. Comparing offline tool, it have online +programmability (see below examples); Comparing online tool, it provides a +generic API for many HWs; Comparing generic online tool/API for many products, +it provides a capability to switch driver dynamically. + +There are various means to reach same goal, we'll try to find the best/better +way to approach. All above advantages will help prgdev to be a 'better choice'. + + +Scope +- + +The target devices include but not limited to programmable NIC, FPGA, GPU. +Any devices, having the capability to store/load a piece of info to/from +the deivce then changed hardware behavior, and applicable to prgdev programming +model, could be registered as a prgdev device. + +The device can be programmed (dynamic) within DPDK or have been prior programmed +(static) prior to a DPDK application being launched. + +Static example: In a static example a program, bitstream or other firmware +would have been loaded prior to the start of a DPDK application. The prgdev +would recognize the firmware loaded, and instantiate higher level interfaces +(example : PMD, L3 forwarding, flow, etc.). + +Dynamic example: In a dynamic example, the programmability of the program, +bitstream or other firmware would be loaded by the DPDK application upon start +, or during execution. The prgdev would offer the interface to allow the DPDK +application to program the device. + +Dyanamic bind/unbind + + +Besides the simple API to upload/download image, the prgdev also introduces a +mechanism internally to switch drivers and register/unregister device on the +fly. With this mechanism, apps can use the programmable device, unbind other +personalities on demand, then program it and bind it back with new personalities +. Apps can follow below examples to simply complete the whole process. + +Note that bind/unbind actions are different concept from that a whole device +attach/detach. For example, rte_eal_dev_detach(), which will try to detach the +drivers with device and remove the whole device from specific class of devices +(ethdev, for example). Then, the whole device is invisible until a new 'probe' +is activated. + +During the whole procedure of image upload/download, prgdev handler is always +valid and apps can use it operate on
[dpdk-dev] [RFC 0/2] Prgdev API
This RFC patch intends to introduce an new abstraction layer API called prgdev to program programmable devices. Please refer to doc and API for details. Chen Jing D(Mark) (2): doc: introduction to prgdev prgdev: introduce generic prgdev API doc/guides/prog_guide/prgdev_lib.rst | 457 ++ lib/librte_prgdev/rte_prgdev.h | 242 ++ 2 files changed, 699 insertions(+), 0 deletions(-) create mode 100644 doc/guides/prog_guide/prgdev_lib.rst create mode 100644 lib/librte_prgdev/rte_prgdev.h -- 1.7.7.6
[dpdk-dev] [PATCH v2 3/4] net/i40e: parse more VF parameter and configure
When VF requested to configure TX queue, a few parameters are missed to be configured in PF host. This change have more fields parsed and configured for TX context. Signed-off-by: Chen Jing D(Mark) --- drivers/net/i40e/i40e_pf.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c index fd83c16..f12a6aa 100644 --- a/drivers/net/i40e/i40e_pf.c +++ b/drivers/net/i40e/i40e_pf.c @@ -400,10 +400,12 @@ /* clear the context structure first */ memset(&tx_ctx, 0, sizeof(tx_ctx)); - tx_ctx.new_context = 1; tx_ctx.base = txq->dma_ring_addr / I40E_QUEUE_BASE_ADDR_UNIT; tx_ctx.qlen = txq->ring_len; tx_ctx.rdylist = rte_le_to_cpu_16(vf->vsi->info.qs_handle[0]); + tx_ctx.head_wb_ena = txq->headwb_enabled; + tx_ctx.head_wb_addr = txq->dma_headwb_addr; + err = i40e_clear_lan_tx_queue_context(hw, abs_queue_id); if (err != I40E_SUCCESS) return err; -- 1.7.7.6
[dpdk-dev] [PATCH v2 4/4] net/i40e: support Linux VF to configure IRQ link list
i40e PF host only support to work with DPDK VF driver, Linux
VF driver is not supported. This change will enhance in
configuring IRQ link list.
This Change will identify VF client by number of vector
requested. DPDK VF will ask only single one while Linux VF
will request at least 2. It will have different configuration
for different clients. DPDK VF will be configured to link all
queue together, while Linux VF will be configured per request.
Signed-off-by: Chen Jing D(Mark)
---
drivers/net/i40e/i40e_pf.c | 152
1 files changed, 139 insertions(+), 13 deletions(-)
diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index f12a6aa..384dfe9 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -546,13 +546,116 @@
return ret;
}
+static void
+i40e_pf_config_irq_link_list(struct i40e_pf_vf *vf,
+ struct i40e_virtchnl_vector_map *vvm)
+{
+#define BITS_PER_CHAR 8
+ uint64_t linklistmap = 0, tempmap;
+ struct i40e_hw *hw = I40E_PF_TO_HW(vf->pf);
+ uint16_t qid;
+ bool b_first_q = true;
+ enum i40e_queue_type qtype;
+ uint16_t vector_id;
+ uint32_t reg, reg_idx;
+ uint16_t itr_idx = 0, i;
+
+ vector_id = vvm->vector_id;
+ /* setup the head */
+ if (!vector_id)
+ reg_idx = I40E_VPINT_LNKLST0(vf->vf_idx);
+ else
+ reg_idx = I40E_VPINT_LNKLSTN(
+ ((hw->func_caps.num_msix_vectors_vf - 1) * vf->vf_idx)
+ + (vector_id - 1));
+
+ if (vvm->rxq_map == 0 && vvm->txq_map == 0) {
+ I40E_WRITE_REG(hw, reg_idx,
+ I40E_VPINT_LNKLST0_FIRSTQ_INDX_MASK);
+ goto cfg_irq_done;
+ }
+
+ /* sort all rx and tx queues */
+ tempmap = vvm->rxq_map;
+ for (i = 0; i < sizeof(vvm->rxq_map) * BITS_PER_CHAR; i++) {
+ if (tempmap & 0x1)
+ linklistmap |= (1 << (2 * i));
+ tempmap >>= 1;
+ }
+
+ tempmap = vvm->txq_map;
+ for (i = 0; i < sizeof(vvm->txq_map) * BITS_PER_CHAR; i++) {
+ if (tempmap & 0x1)
+ linklistmap |= (1 << (2 * i + 1));
+ tempmap >>= 1;
+ }
+
+ /* Link all rx and tx queues into a chained list */
+ tempmap = linklistmap;
+ i = 0;
+ b_first_q = true;
+ do {
+ if (tempmap & 0x1) {
+ qtype = (enum i40e_queue_type)(i % 2);
+ qid = vf->vsi->base_queue + i / 2;
+ if (b_first_q) {
+ /* This is header */
+ b_first_q = false;
+ reg = ((qtype <<
+ I40E_VPINT_LNKLSTN_FIRSTQ_TYPE_SHIFT)
+ | qid);
+ } else {
+ /* element in the link list */
+ reg = (vector_id) |
+ (qtype << I40E_QINT_RQCTL_NEXTQ_TYPE_SHIFT) |
+ (qid << I40E_QINT_RQCTL_NEXTQ_INDX_SHIFT) |
+ BIT(I40E_QINT_RQCTL_CAUSE_ENA_SHIFT) |
+ (itr_idx << I40E_QINT_RQCTL_ITR_INDX_SHIFT);
+ }
+ I40E_WRITE_REG(hw, reg_idx, reg);
+ /* find next register to program */
+ switch (qtype) {
+ case I40E_QUEUE_TYPE_RX:
+ reg_idx = I40E_QINT_RQCTL(qid);
+ itr_idx = vvm->rxitr_idx;
+ break;
+ case I40E_QUEUE_TYPE_TX:
+ reg_idx = I40E_QINT_TQCTL(qid);
+ itr_idx = vvm->txitr_idx;
+ break;
+ default:
+ break;
+ }
+ }
+ i++;
+ tempmap >>= 1;
+ } while (tempmap);
+
+ /* Terminate the link list */
+ reg = (vector_id) |
+ (0 << I40E_QINT_RQCTL_NEXTQ_TYPE_SHIFT) |
+ (0x7FF << I40E_QINT_RQCTL_NEXTQ_INDX_SHIFT) |
+ BIT(I40E_QINT_RQCTL_CAUSE_ENA_SHIFT) |
+ (itr_idx << I40E_QINT_RQCTL_ITR_INDX_SHIFT);
+ I40E_WRITE_REG(hw, reg_idx, reg);
+
+cfg_irq_done:
+ I40E_WRITE_FLUSH(hw);
+}
+
static int
i40e_pf_host_process_cmd_config_irq_map(struct i40e_pf_vf *vf,
uint8_t *msg, uint16_t msglen)
{
int ret = I40E_SUCCESS;
+ struct i40e_pf *pf = vf->pf;
+ struct i40e_hw *hw = I40E_PF_TO_HW(vf->pf);
struct
[dpdk-dev] [PATCH v2 1/4] net/i40e: change version number to support Linux VF
i40e PF host only support to work with DPDK VF driver, Linux
VF driver is not supported. This change will enhance in version
number returned.
Current version info returned won't be able to be recognized
by Linux VF driver, change to values that both DPDK VF and Linux
driver can recognize.
The expense is original DPDK host specific feature like
CFG_VLAN_PVID and CONFIG_VSI_QUEUES_EXT will not available.
DPDK VF also can't identify host driver by version number returned.
It always assume talking with Linux PF.
Signed-off-by: Chen Jing D(Mark)
---
drivers/net/i40e/i40e_pf.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index ddfc140..fa4af2b 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -276,8 +276,16 @@
{
struct i40e_virtchnl_version_info info;
- info.major = I40E_DPDK_VERSION_MAJOR;
- info.minor = I40E_DPDK_VERSION_MINOR;
+ /* Respond like a Linux PF host in order to support both DPDK VF and
+* Linux VF driver. The expense is original DPDK host specific feature
+* like CFG_VLAN_PVID and CONFIG_VSI_QUEUES_EXT will not available.
+*
+* DPDK VF also can't identify host driver by version number returned.
+* It always assume talking with Linux PF.
+*/
+ info.major = I40E_VIRTCHNL_VERSION_MAJOR;
+ info.minor = I40E_VIRTCHNL_VERSION_MINOR_NO_VF_CAPS;
+
i40e_pf_host_send_msg_to_vf(vf, I40E_VIRTCHNL_OP_VERSION,
I40E_SUCCESS, (uint8_t *)&info, sizeof(info));
}
--
1.7.7.6
[dpdk-dev] [PATCH v2 2/4] net/i40e: return correct VSI id
PF host didn't return correct VSI id to VF. This change fix it. Signed-off-by: Chen Jing D(Mark) --- drivers/net/i40e/i40e_pf.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c index fa4af2b..fd83c16 100644 --- a/drivers/net/i40e/i40e_pf.c +++ b/drivers/net/i40e/i40e_pf.c @@ -329,8 +329,7 @@ /* Change below setting if PF host can support more VSIs for VF */ vf_res->vsi_res[0].vsi_type = I40E_VSI_SRIOV; - /* As assume Vf only has single VSI now, always return 0 */ - vf_res->vsi_res[0].vsi_id = 0; + vf_res->vsi_res[0].vsi_id = vf->vsi->vsi_id; vf_res->vsi_res[0].num_queue_pairs = vf->vsi->nb_qps; ether_addr_copy(&vf->mac_addr, (struct ether_addr *)vf_res->vsi_res[0].default_mac_addr); -- 1.7.7.6
[dpdk-dev] [PATCH v2 0/4] enhancement to i40e PF host driver
v2: - add macro to replace numeric - rework comments Current PF host driver can serve DPDK VF well, but the implementation is not complete to support Linux VF, even both DPDK VF and Linux VF use same API set. Note that the patch are experimental for use and might be removed without prior notice. This patch set made below changes: 1. Make an enhancement on interface to serve VF, so both Linux and DPDK VF can be well served. 2. Change API version number so both DPDK and Linux VF can recognize and select proper command and data structure to request service. But the sacrifice is DPDK VF can't identify host driver (Linux or DPDK) and extended function provided in DPDK PF host driver can't be used. This situation will change after negotiate with Linux maintainer to provide a better mechanism to identify both PF and VF function. Chen Jing D(Mark) (4): net/i40e: change version number to support Linux VF net/i40e: return correct VSI id net/i40e: parse more VF parameter and configure net/i40e: support Linux VF to configure IRQ link list drivers/net/i40e/i40e_pf.c | 171 +++- 1 files changed, 153 insertions(+), 18 deletions(-) -- 1.7.7.6
Re: [dpdk-dev] fm10k pmd limitations
> -Original Message- > From: Yigit, Ferruh > Sent: Thursday, January 12, 2017 7:57 PM > To: Shaham Fridenberg ; dev@dpdk.org > Cc: Chen, Jing D > Subject: Re: [dpdk-dev] fm10k pmd limitations > > On 12/13/2016 1:49 PM, Shaham Fridenberg wrote: > > Hey guys, > > > > I'm using dpdk 16.4 and fm10k card. According to the code, there's no > support for disabling vlan stripping and VLAN QinQ in pmd fm10k. > > Does anybody know why? If there's any way to work-around it, or when is a > behavior change expected? Yes, HW will always strip it and driver will copy it into (struct rte_mbuf *)mbuf->vlan_tci. > > I need my VF to receive the packets with the VLAN headers. VF can read from rte_mbuf. > > Even if it's possible to change this configurations through the linux kernel > fm10k driver? > > > > Thanks! > > > > CC fm10k maintainer: Jing Chen
Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e
Hi, Vincent, > -Original Message- > From: Vincent JARDIN [mailto:vincent.jar...@6wind.com] > Sent: Tuesday, January 10, 2017 9:30 PM > To: Scott Daniels ; dev@dpdk.org > Cc: kaust...@research.att.com; az5...@att.com; Chen, Jing D > > Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF > on > i40e > > Hi Scott, > > Le 04/01/2017 à 22:09, Scott Daniels a écrit : > > With holidays we are a bit late with our thoughts, but would like to > > toss them into the mix. > > Same, I hope I am not missing emails. I do appreciate your arguments, it > provides lot of light. See below, > > > The original NAK is understandable, however having the ability to > > configure the PF via DPDK is advantageous for several reasons: > > > > 1) While some functions may be duplicated and/or available from the kernel > > driver, it is often not possible to introduce new kernel drivers into > > production without a large amount of additional testing of the entire > > platform which can cause a significant delay when introducing a DPDK based > > product. If the PF control is a part of the DPDK environment, then only > > the application needs to pass the operational testing before deployment; a > > much more simple task. > > So we agree: you confirm that your foresee the benefits of using DPDK to > *bypass the role of the Kernel being the PF* of reference for the > hypervisor. > > > 2) If the driver changes are upstreamed into the kernel proper, the > > difficulty of operational readiness testing increases as a new kernel is > > introduced, and further undermines the ability to quickly and easily > > release a DPDK based application into production. While the application > > may eventually fall back on driver and/or kernel support, this could be > > years away. > > I do agree with the benefits of the agilities and the upsides it brings. > But they are other options to get the same agility without creating a > fragmentation of PFs. > > For example, you do not have to update the whole kernel, you can just > update the PF kernel module that can be upgraded with the latest needed > features. > > > 3) As DPDK is being used to configure the NIC, it just seems to make > > sense, for consistency, that the configuration capabilities should include > > the ability to configure the PF as is proposed. > > From this perspective, the kernel modules are fine for the PF: most > kernels of hypervisors support it without the need to upgrade their kernels. > > To summarize, I understand that you need a flexible way to upgrade PF > features without touching/changing the kernel. So let's check the kernel > module option? VFD brings some interesting capabilities, could it be a > way to push and stimulate the i40e features instead of using DPDK? > >https://sourceforge.net/projects/e1000/files/i40e%20stable/ > for instance could be better stimulated. May I ask what if DPDK VF need a new extension function from PF? Then, we'll have to build kernel community expertise and submit patch to Linux PF and wait for merge. Your proposal indicates DPDK community submitters will have to ask Linux community to authorize if we'll have any requirements in DPDK VF. Comparing fragmentation, the extra dependency worry me most. Can you imagine how long it will be for any VF features gets ready?
[dpdk-dev] [PATCH 4/4] net/i40e: support Linux VF to configure IRQ link list
i40e PF host only support to work with DPDK VF driver, Linux
VF driver is not supported. This change will enhance in
configuring IRQ link list.
This Change will identify VF client by number of vector
requested. DPDK VF will ask only single one while Linux VF
will request at least 2. It will have different configuration
for different clients. DPDK VF will be configured to link all
queue together, while Linux VF will be configured per request.
Signed-off-by: Chen Jing D(Mark)
---
drivers/net/i40e/i40e_pf.c | 151
1 files changed, 138 insertions(+), 13 deletions(-)
diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index 75c5f03..eee5e85 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -552,13 +552,115 @@
return ret;
}
+static void
+i40e_pf_config_irq_link_list(struct i40e_pf_vf *vf,
+ struct i40e_virtchnl_vector_map *vvm)
+{
+ uint64_t linklistmap = 0, tempmap;
+ struct i40e_hw *hw = I40E_PF_TO_HW(vf->pf);
+ uint16_t qid;
+ bool b_first_q = true;
+ enum i40e_queue_type qtype;
+ uint16_t vector_id;
+ uint32_t reg, reg_idx;
+ uint16_t itr_idx = 0, i;
+
+ vector_id = vvm->vector_id;
+ /* setup the head */
+ if (!vector_id)
+ reg_idx = I40E_VPINT_LNKLST0(vf->vf_idx);
+ else
+ reg_idx = I40E_VPINT_LNKLSTN(
+ ((hw->func_caps.num_msix_vectors_vf - 1) * vf->vf_idx)
+ + (vector_id - 1));
+
+ if (vvm->rxq_map == 0 && vvm->txq_map == 0) {
+ I40E_WRITE_REG(hw, reg_idx,
+ I40E_VPINT_LNKLST0_FIRSTQ_INDX_MASK);
+ goto cfg_irq_done;
+ }
+
+ /* sort all rx and tx queues */
+ tempmap = vvm->rxq_map;
+ for (i = 0; i < sizeof(vvm->rxq_map) * 8; i++) {
+ if (tempmap & 0x1)
+ linklistmap |= (1 << (2 * i));
+ tempmap >>= 1;
+ }
+
+ tempmap = vvm->txq_map;
+ for (i = 0; i < sizeof(vvm->txq_map) * 8; i++) {
+ if (tempmap & 0x1)
+ linklistmap |= (1 << (2 * i + 1));
+ tempmap >>= 1;
+ }
+
+ /* Link all rx and tx queues into a chained list */
+ tempmap = linklistmap;
+ i = 0;
+ b_first_q = true;
+ do {
+ if (tempmap & 0x1) {
+ qtype = (enum i40e_queue_type)(i % 2);
+ qid = vf->vsi->base_queue + i / 2;
+ if (b_first_q) {
+ /* This is header */
+ b_first_q = false;
+ reg = ((qtype <<
+ I40E_VPINT_LNKLSTN_FIRSTQ_TYPE_SHIFT)
+ | qid);
+ } else {
+ /* element in the link list */
+ reg = (vector_id) |
+ (qtype << I40E_QINT_RQCTL_NEXTQ_TYPE_SHIFT) |
+ (qid << I40E_QINT_RQCTL_NEXTQ_INDX_SHIFT) |
+ BIT(I40E_QINT_RQCTL_CAUSE_ENA_SHIFT) |
+ (itr_idx << I40E_QINT_RQCTL_ITR_INDX_SHIFT);
+ }
+ I40E_WRITE_REG(hw, reg_idx, reg);
+ /* find next register to program */
+ switch (qtype) {
+ case I40E_QUEUE_TYPE_RX:
+ reg_idx = I40E_QINT_RQCTL(qid);
+ itr_idx = vvm->rxitr_idx;
+ break;
+ case I40E_QUEUE_TYPE_TX:
+ reg_idx = I40E_QINT_TQCTL(qid);
+ itr_idx = vvm->txitr_idx;
+ break;
+ default:
+ break;
+ }
+ }
+ i++;
+ tempmap >>= 1;
+ } while (tempmap);
+
+ /* Terminate the link list */
+ reg = (vector_id) |
+ (0 << I40E_QINT_RQCTL_NEXTQ_TYPE_SHIFT) |
+ (0x7FF << I40E_QINT_RQCTL_NEXTQ_INDX_SHIFT) |
+ BIT(I40E_QINT_RQCTL_CAUSE_ENA_SHIFT) |
+ (itr_idx << I40E_QINT_RQCTL_ITR_INDX_SHIFT);
+ I40E_WRITE_REG(hw, reg_idx, reg);
+
+cfg_irq_done:
+ I40E_WRITE_FLUSH(hw);
+}
+
static int
i40e_pf_host_process_cmd_config_irq_map(struct i40e_pf_vf *vf,
uint8_t *msg, uint16_t msglen)
{
int ret = I40E_SUCCESS;
+ struct i40e_pf *pf = vf->pf;
+ struct i40e_hw *hw = I40E_PF_TO_HW(vf->pf);
struct i40e_virtchnl_irq_map_info *irqmap =
[dpdk-dev] [PATCH 2/4] net/i40e: return correct VSI id
PF host didn't return correct VSI id to VF. This change fix it. Signed-off-by: Chen Jing D(Mark) --- drivers/net/i40e/i40e_pf.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c index 229f71a..5314d9f 100644 --- a/drivers/net/i40e/i40e_pf.c +++ b/drivers/net/i40e/i40e_pf.c @@ -335,8 +335,7 @@ /* Change below setting if PF host can support more VSIs for VF */ vf_res->vsi_res[0].vsi_type = I40E_VSI_SRIOV; - /* As assume Vf only has single VSI now, always return 0 */ - vf_res->vsi_res[0].vsi_id = 0; + vf_res->vsi_res[0].vsi_id = vf->vsi->vsi_id; vf_res->vsi_res[0].num_queue_pairs = vf->vsi->nb_qps; ether_addr_copy(&vf->mac_addr, (struct ether_addr *)vf_res->vsi_res[0].default_mac_addr); -- 1.7.7.6
[dpdk-dev] [PATCH 3/4] net/i40e: parse more VF parameter and configure
When VF requested to configure TX queue, a few parameters are missed to be configured in PF host. This change have more fields parsed and configured for TX context. Signed-off-by: Chen Jing D(Mark) --- drivers/net/i40e/i40e_pf.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c index 5314d9f..75c5f03 100644 --- a/drivers/net/i40e/i40e_pf.c +++ b/drivers/net/i40e/i40e_pf.c @@ -406,10 +406,12 @@ /* clear the context structure first */ memset(&tx_ctx, 0, sizeof(tx_ctx)); - tx_ctx.new_context = 1; tx_ctx.base = txq->dma_ring_addr / I40E_QUEUE_BASE_ADDR_UNIT; tx_ctx.qlen = txq->ring_len; tx_ctx.rdylist = rte_le_to_cpu_16(vf->vsi->info.qs_handle[0]); + tx_ctx.head_wb_ena = txq->headwb_enabled; + tx_ctx.head_wb_addr = txq->dma_headwb_addr; + err = i40e_clear_lan_tx_queue_context(hw, abs_queue_id); if (err != I40E_SUCCESS) return err; -- 1.7.7.6
[dpdk-dev] [PATCH 1/4] net/i40e: change version number to support Linux VF
i40e PF host only support to work with DPDK VF driver, Linux
VF driver is not supported. This change will enhance in version
number returned.
Current version info returned won't be able to be recognized
by Linux VF driver, change to values that both DPDK VF and Linux
driver can recognize.
The expense is original DPDK host specific feature like
CFG_VLAN_PVID and CONFIG_VSI_QUEUES_EXT will not available.
DPDK VF also can't identify host driver by version number returned.
It always assume talking with Linux PF.
Signed-off-by: Chen Jing D(Mark)
---
drivers/net/i40e/i40e_pf.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c
index 97b8ecc..229f71a 100644
--- a/drivers/net/i40e/i40e_pf.c
+++ b/drivers/net/i40e/i40e_pf.c
@@ -278,8 +278,20 @@
{
struct i40e_virtchnl_version_info info;
- info.major = I40E_DPDK_VERSION_MAJOR;
- info.minor = I40E_DPDK_VERSION_MINOR;
+ /* Respond like a Linux PF host in order to support both DPDK VF and
+* Linux VF driver. The expense is original DPDK host specific feature
+* like CFG_VLAN_PVID and CONFIG_VSI_QUEUES_EXT will not available.
+*
+* DPDK VF also can't identify host driver by version number returned.
+* It always assume talking with Linux PF.
+*
+* TODO:
+* Discuss with Linux driver maintainer if possible to carry more info
+* in this function to identify it's Linux or DPDK host.
+*/
+ info.major = I40E_VIRTCHNL_VERSION_MAJOR;
+ info.minor = I40E_VIRTCHNL_VERSION_MINOR_NO_VF_CAPS;
+
i40e_pf_host_send_msg_to_vf(vf, I40E_VIRTCHNL_OP_VERSION,
I40E_SUCCESS, (uint8_t *)&info, sizeof(info));
}
--
1.7.7.6
[dpdk-dev] [PATCH 0/4] enhancement to i40e PF host driver
Current PF host driver can serve DPDK VF well, but the implementation is not complete to support Linux VF, even both DPDK VF and Linux VF use same API set. This patch set made below changes: 1. Make an enhancement on interface to serve VF, so both Linux and DPDK VF can be well served. 2. Change API version number so both DPDK and Linux VF can recognize and select proper command and data structure to request service. But the sacrifice is DPDK VF can't identify host driver (Linux or DPDK) and extended function provided in DPDK PF host driver can't be used. This situation will change after negotiate with Linux maintainer to provide a better mechanism to identify both PF and VF function. Chen Jing D(Mark) (4): net/i40e: change version number to support Linux VF net/i40e: return correct VSI id net/i40e: parse more VF parameter and configure net/i40e: support Linux VF to configure IRQ link list drivers/net/i40e/i40e_pf.c | 174 +++- 1 files changed, 156 insertions(+), 18 deletions(-) -- 1.7.7.6
Re: [dpdk-dev] [PATCH 0/4] enhancement to i40e PF host driver
Hi, Vincent, Since original patch set are split into 2 different patches, can we discuss in this thread? Attach original discussion below. Sorry for top-post. > > Le 22/12/2016 à 09:10, Chen, Jing D a écrit : > > In the meanwhile, we have some test models ongoing to validate > > combination of Linux and DPDK drivers for VF and PF. We'll fully > > support > below 4 cases going forward. > > 1. DPDK PF + DPDK VF > > 2. DPDK PF + Linux VF > > + DPDK PF + FreeBSD VF > + DPDK PF + Windows VF > + DPDK PF + OS xyz VF > If all drivers follow same API spec, what's the problem here? What extra DPDK PF effort you observed? > > 3. Linux PF + DPDK VF > > 4. Linux PF + Linux VF (it's not our scope) > > So, you confirm the issue: having DPDK becoming a PF, even if SRIOV > protocol includes version-ing, it doubles the combinatory cases. If extended functions are needed, the answer is yes. That's not a big problem, right? I have several workarounds/approaches to support extended funcs while following original API spec. I can fix it in this release. In order to have a mature solution, I left it here for further implementation. > > > > > After applied this patch, i've done below test without observing > compatibility issue. > > 1. DPDK PF + DPDK VF (middle of 16.11 and 17.02 code base). PF to > > support > API 1.0 while VF > > to support API 1.1/1.0 > > 2. DPDK PF + Linux VF 1.5.14. PF to support 1.0, while Linux to > > support 1.1/1.0 > > > > Linux PF + DPDK VF has been tested with 1.0 API long time ago. There > > is some test activities ongoing. > > > > Finally, please give strong reasons to support your NAC. > > I feel bad because I do recognize the strong and hard work that you > have done on this PF development, but I feel we need first to assess > if DPDK should become a PF or not. I know ixgbe did open the path and > that they are some historical DPDK PF supports in Intel NICs, but > before we generalize it, we have to make sure we are not turning this > DataPlane development Kit into a ControlPlane Driver Kit that we are > scared to upstream into Linux kernel. Even if "DPDK is not Linux", it > does not mean that Linux should be ignored. In case of DPDK on other OS, > same, their PF could be extended too. > Thanks for the recognition of our work on PF driver. :) > So currently, yes, I do keep a nack't > > Since DPDK PF features can be into Linux PF features too and since > Linux (and other hypervisors) has already some tools to manage PF (see > iproute2, etc.), why should we have an other management path with DPDK? > DPDK is aimed to be a Dataplane Development kit, not a > management/control plane driver kit. Before we debated on Dataplane and ControPlane, can you answer me a question, why we have generic filter API? Is it a API for dataplane? I can't imagine that we'll have to say 'you need to use Linux PF' driver when users want to deploy PF + VF cases. Why we can't provide an alternative option. they are not exclusive and users can decide which combination is better for them. The reason why we developed DPDK PF host driver is we have requirements from users. Our motivation is simple, there are requirements, we satisfy them. Sorry, you NACK can't convince me. > > Assuming you want to use DPDK PF for dataplane feature, that could be > OK then, using: >- configure one VF on the hypervisor from Linux's PF, let's name if > VF_forPFtraffic, see http://dpdk.org/doc/guides/howto/flow_bifurcation.html >- have no (or few IO)s to the PF's queue >- assign the traffic to all VF_forPFtraffic's queues of the hypervisor, >- run DPDK into the hypervisor's VF_forPFtraffic > > Doing so, we get the same benefit of running DPDK over PF or running > DPDK over VF_forPFtraffic, don't we? It is a benefit of: >http://dpdk.org/doc/guides/howto/flow_bifurcation.html > > Thank you, >Vincent > > -Original Message- > From: Vincent JARDIN [mailto:vincent.jar...@6wind.com] > Sent: Friday, December 23, 2016 8:53 PM > To: Chen, Jing D ; dev@dpdk.org > Cc: Yigit, Ferruh ; Wu, Jingjing > > Subject: Re: [PATCH 0/4] enhancement to i40e PF host driver > > Thanks for this update. > > Still, I would like to get good arguments why DPDK should be a PF because it > creates fragmentations. Please, first, let's reply to: >http://dpdk.org/ml/archives/dev/2016-December/053107.html > > Having both Linux and DPDK being PF, it means that we double the > combinations so we double the issues. > > The following should be used instead: assuming you want
Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e
Vincent, Sorry, I missed this reply. > > Le 22/12/2016 à 09:10, Chen, Jing D a écrit : > > In the meanwhile, we have some test models ongoing to validate > > combination of Linux and DPDK drivers for VF and PF. We'll fully support > below 4 cases going forward. > > 1. DPDK PF + DPDK VF > > 2. DPDK PF + Linux VF > > + DPDK PF + FreeBSD VF > + DPDK PF + Windows VF > + DPDK PF + OS xyz VF > If all drivers follow same API spec, what's the problem here? What extra DPDK PF effort you observed? > > 3. Linux PF + DPDK VF > > 4. Linux PF + Linux VF (it's not our scope) > > So, you confirm the issue: having DPDK becoming a PF, even if SRIOV protocol > includes version-ing, it doubles the combinatory cases. If extended functions are needed, the answer is yes. That's not a big problem, right? I have several workarounds/approaches to support extended funcs while following original API spec. I can fix it in this release. In order to have a mature solution, I left it here for further implementation. > > > > > After applied this patch, i've done below test without observing > compatibility issue. > > 1. DPDK PF + DPDK VF (middle of 16.11 and 17.02 code base). PF to support > API 1.0 while VF > > to support API 1.1/1.0 > > 2. DPDK PF + Linux VF 1.5.14. PF to support 1.0, while Linux to > > support 1.1/1.0 > > > > Linux PF + DPDK VF has been tested with 1.0 API long time ago. There > > is some test activities ongoing. > > > > Finally, please give strong reasons to support your NAC. > > I feel bad because I do recognize the strong and hard work that you have done > on this PF development, but I feel we need first to assess if DPDK should > become a PF or not. I know ixgbe did open the path and that they are some > historical DPDK PF supports in Intel NICs, but before we generalize it, we > have > to make sure we are not turning this DataPlane development Kit into a > ControlPlane Driver Kit that we are scared to upstream into Linux kernel. Even > if "DPDK is not Linux", it does not mean that Linux should be ignored. In case > of DPDK on other OS, same, their PF could be extended too. > Thanks for the recognition of our work on PF driver. :) > So currently, yes, I do keep a nack't > > Since DPDK PF features can be into Linux PF features too and since Linux (and > other hypervisors) has already some tools to manage PF (see iproute2, etc.), > why should we have an other management path with DPDK? > DPDK is aimed to be a Dataplane Development kit, not a management/control > plane driver kit. Before we debated on Dataplane and ControPlane, can you answer me a question, why we have generic filter API? Is it a API for dataplane? I can't imagine that we'll have to say 'you need to use Linux PF' driver when users want to deploy PF + VF cases. Why we can't provide an alternative option. they are not exclusive and users can decide which combination is better for them. The reason why we developed DPDK PF host driver is we have requirements from users. Our motivation is simple, there are requirements, we satisfy them. Sorry, you NACK can't convince me. > > Assuming you want to use DPDK PF for dataplane feature, that could be OK > then, using: >- configure one VF on the hypervisor from Linux's PF, let's name if > VF_forPFtraffic, see http://dpdk.org/doc/guides/howto/flow_bifurcation.html >- have no (or few IO)s to the PF's queue >- assign the traffic to all VF_forPFtraffic's queues of the hypervisor, >- run DPDK into the hypervisor's VF_forPFtraffic > > Doing so, we get the same benefit of running DPDK over PF or running DPDK > over VF_forPFtraffic, don't we? It is a benefit of: >http://dpdk.org/doc/guides/howto/flow_bifurcation.html > > Thank you, >Vincent >
Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e
Hi, Vincent,
> -Original Message-
> From: Vincent JARDIN [mailto:vincent.jar...@6wind.com]
> Sent: Tuesday, December 20, 2016 11:19 PM
> To: Chen, Jing D ; Thomas Monjalon
>
> Cc: dev@dpdk.org; Yigit, Ferruh ; Wu, Jingjing
> ; Zhang, Helin
> Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF
> on
> i40e
>
> Le 20/12/2016 à 05:48, Chen, Jing D a écrit :
> > That's a collaboration with another team. we'll follow-up that but not
> > guarantee
> > it will happen.
> > May I ask if my reply make it clear? Still NAC for this patch?
>
> Yes still nack, I am not confident with this PF approach since you are
> breaking Linux PF behavior. It does not provide guarantees with PF.
> Something is missing to guarantee the compatibilities.
Let me introduce the rationale of API between PF and VF.
There is a common head file visible to both PF and VF, which includes a set of
command
and data structures, which is managed by a version number. Below is an example.
Major_verion=1
Minor_verion=1
enum i40e_virtchnl_ops {
CMD_GET_VERSION,
CMD_RESET_VF,
..
}
struct i40e_virtchnl_version_info {
u32 major;
u32 minor;
};
..
So, both PF and VF strictly follow the spec. VF send request with expected
command and
data structures to PF host. PF do sanity check and configure, finally applied
to HW.
As developing the code, it's possible to have multiple version of API occurred
with 'major_verion'
or 'minor_version' changed. So, at the initialization stage, VF and PF will use
a command
'CMD_GET_VERSION' to negotiate what language (what version of API) they should
use
and setup conversation.
So, from my perspective, there is no issue here.
In the meanwhile, we have some test models ongoing to validate combination of
Linux and
DPDK drivers for VF and PF. We'll fully support below 4 cases going forward.
1. DPDK PF + DPDK VF
2. DPDK PF + Linux VF
3. Linux PF + DPDK VF
4. Linux PF + Linux VF (it's not our scope)
After applied this patch, i've done below test without observing compatibility
issue.
1. DPDK PF + DPDK VF (middle of 16.11 and 17.02 code base). PF to support API
1.0 while VF
to support API 1.1/1.0
2. DPDK PF + Linux VF 1.5.14. PF to support 1.0, while Linux to support 1.1/1.0
Linux PF + DPDK VF has been tested with 1.0 API long time ago. There is some
test activities
ongoing.
Finally, please give strong reasons to support your NAC.
Re: [dpdk-dev] [PATCH] net/fm10k/base: add a break statement
Hi, Chenghu, > -Original Message- > From: Chenghu Yao [mailto:yao.chen...@zte.com.cn] > Sent: Wednesday, December 21, 2016 11:05 AM > To: Chen, Jing D > Cc: dev@dpdk.org; Chenghu Yao > Subject: [PATCH] net/fm10k/base: add a break statement > > In function fm10k_mbx_create_reply(), the last case branch > has no break statement. > > Signed-off-by: Chenghu Yao > --- > drivers/net/fm10k/base/fm10k_mbx.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/fm10k/base/fm10k_mbx.c > b/drivers/net/fm10k/base/fm10k_mbx.c > index 2e70434..45d6ddb 100644 > --- a/drivers/net/fm10k/base/fm10k_mbx.c > +++ b/drivers/net/fm10k/base/fm10k_mbx.c > @@ -1084,6 +1084,7 @@ STATIC s32 fm10k_mbx_create_reply(struct fm10k_hw > *hw, > case FM10K_STATE_CLOSED: > /* generate new header based on data */ > fm10k_mbx_create_disconnect_hdr(mbx); > + break; > default: > break; > } Thanks for contributing code. But there are 2 problems here. 1. You are modifying base code under 'base' directory. It assumed READ ONLY because there is another Intel team are maintaining it. 2. Without your change, the code won't have any negative effect. Yes, I appreciate your change to make it stronger. So, I'd to say 'NAC' for this patch.
Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e
Hi, > -Original Message- > From: Vincent JARDIN [mailto:vincent.jar...@6wind.com] > Sent: Monday, December 19, 2016 9:46 PM > To: Chen, Jing D ; Thomas Monjalon > > Cc: dev@dpdk.org; Yigit, Ferruh ; Wu, Jingjing > ; Zhang, Helin > Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF > on > i40e > > Le 19/12/2016 à 14:39, Chen, Jing D a écrit : > > They will > > have concern why VM can have such privilege (like promisc mode). But I need > > to check as I know there is some mechanism now to make a VM privileged. > > From iproute2's man: > <-- > trust on|off - trust the specified VF user. This enables that VF user > can set a specific feature which may impact security and/or performance. > (e.g. VF multicast promiscuous mode) > --> > > So yes, it is possible to get PF features upstream'd into the kernel > without having a specific PF into DPDK. That's a collaboration with another team. we'll follow-up that but not guarantee it will happen. May I ask if my reply make it clear? Still NAC for this patch?
Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Monday, December 19, 2016 9:21 PM > To: Chen, Jing D > Cc: dev@dpdk.org; Vincent JARDIN ; Yigit, Ferruh > ; Wu, Jingjing ; Zhang, Helin > > Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel > VF on i40e > > 2016-12-19 09:01, Chen, Jing D: > > Since then, both Linux and DPDK keep developing code. Then, we found > > it's necessary to extend VF capability (Like promiscuous mode). It > > will be hard to ask Linux PF to support that service considering upstream > effort in Linux world. > > Please, could you clarify this? > Do you mean you cannot change the Linux driver? There are 2 things here. One is to add extended functionality into Linux driver, Another is to have it upstream into kernel world. The first one can be achieved easier, while later one may be difficult. They will have concern why VM can have such privilege (like promisc mode). But I need to check as I know there is some mechanism now to make a VM privileged.
Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF on i40e
Hi, Vincent, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Vincent JARDIN > Sent: Saturday, December 17, 2016 4:36 AM > To: Yigit, Ferruh ; dev@dpdk.org > Cc: Wu, Jingjing ; Zhang, Helin > Subject: Re: [dpdk-dev] [PATCH v5 00/29] Support VFD and DPDK PF + kernel VF > on > i40e > > Le 16/12/2016 à 20:02, Ferruh Yigit a écrit : > > As we need to support the scenario kernel PF + DPDK VF, > > DPDK follows the interface between kernel PF + kernel VF. > > Please, it has to be proven that DPDK provides the same interface that > the kernel. It seems insane to duplicate kernel's PF into the DPDK > without a strong guarantee that it is a strict same behaviour. For instance, >- what will happen when the DPDK's PF will have a new feature which > is not into the kernel? >- what will happen when the Kernel's PF will have a feature with > different capabilities that the kernel? > > Please, make it clear before. Currently, for me it is a nack of this serie. > Let me try to explain. When we DPDK developed i40e drivers several years ago, we found the API and data structures defined in shared code for VF and PF device communication can satisfy DPDK's requirements, so we just followed that API. At that time, we'll try to satisfy 3 scenarios. 1. Linux PF + Linux VF : it's not our scope. 2. Linux PF + DPDK VF: there is no problems observed since we use same API. 3. DPDK PF + DPDK VF: that's fully under control. The only scenario was not considered is DPDK PF + Linux VF. Since then, both Linux and DPDK keep developing code. Then, we found it's necessary to extend VF capability (Like promiscuous mode). It will be hard to ask Linux PF to support that service considering upstream effort in Linux world. So, supporting it in scenario of DPDK PF + DPDK VF became best candidate. But how can VF identify who is serving it then decide if extended request can be dispatched? So, DPDK PF will send a special version number for this purpose. As time passed by, we realized there some use case for DPDK PF + Linux VF and it's not supported yet. Then, we found our implementation in DPDK PF is not complete since we only had considered how to serve DPDK VF at that time. So, we need some improvement on the PF host driver. Besides that, 'send a special version' to VF doesn't work now since Linux VF can't interpret the version info. So, we behave the same as Linux PF driver with sacrifice of extended function in DPDK VF. Let me summary the chang here. 1. We shared the same interface with Linux driver from beginning. 2. This change will support both Linux VF and DPDK VF. 3. We'll find a way for DPDK VF identifying who is serving it so it can use extended function in future release.
Re: [dpdk-dev] [PATCH v2 15/32] net/i40e: add VF vlan strip func
Hi, Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Thursday, December 08, 2016 6:43 PM
> To: Chen, Jing D ; Lu, Wenzhuo ;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 15/32] net/i40e: add VF vlan strip func
>
> On 12/8/2016 9:10 AM, Chen, Jing D wrote:
> > HI, Ferruh,
> >
> > Best Regards,
> > Mark
> >
> >
> >> -Original Message-
> >> From: Yigit, Ferruh
> >> Sent: Wednesday, December 07, 2016 10:18 PM
> >> To: Lu, Wenzhuo ; dev@dpdk.org
> >> Cc: Chen, Jing D
> >> Subject: Re: [dpdk-dev] [PATCH v2 15/32] net/i40e: add VF vlan strip func
> >>
> >> On 12/7/2016 3:31 AM, Wenzhuo Lu wrote:
> >>> Add a function to configure vlan strip enable/disable for specific
> >>> SRIOV VF device.
> >>>
> >>> Signed-off-by: Chen Jing D(Mark)
> >>> ---
> >>
> >> <...>
> >>
> >>> +
> >>> +/* Set vlan strip on/off for specific VF from host */
> >>> +int
> >>> +rte_pmd_i40e_set_vf_vlan_stripq(uint8_t port, uint16_t vf_id, uint8_t on)
> >>> +{
> >>> + struct rte_eth_dev *dev;
> >>> + struct i40e_pf *pf;
> >>> + struct i40e_vsi *vsi;
> >>> +
> >>> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> >>> +
> >>> + dev = &rte_eth_devices[port];
> >>> + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> >>> +
> >>> + if (vf_id > pf->vf_num - 1 || !pf->vfs) {
> >>> + PMD_DRV_LOG(ERR, "Invalid argument.");
> >>> + return -EINVAL;
> >>> + }
> >>> +
> >>> + vsi = pf->vfs[vf_id].vsi;
> >>> +
> >>> + if (vsi)
> >>> + return i40e_vsi_config_vlan_stripping(vsi, !!on);
> >>> + else
> >>
> >> if vd_if is valid, can vsi be NULL? If so this check may be required in
> >> some prev patches too.
> >
> > It's a little impossible. This sanity check just make the code stronger.
> >
>
> If it is impossible, do you agree to remove this? And if this can be
> possible we must update other patches, almost all other patches assume
> this can't be NULL.
I'll recommend other patches to add it, too.
The reason is we can't image if there is some code change have impact in
future, the necessary sanity check in slow patch make code stronger.
Re: [dpdk-dev] [PATCH v2 27/32] net/i40e: change version number to support Linux VF
Hi, Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, December 07, 2016 11:14 PM
> To: Lu, Wenzhuo ; dev@dpdk.org
> Cc: Chen, Jing D
> Subject: Re: [dpdk-dev] [PATCH v2 27/32] net/i40e: change version number to
> support Linux VF
>
> On 12/7/2016 3:32 AM, Wenzhuo Lu wrote:
> > i40e PF host only support to work with DPDK VF driver, Linux
> > VF driver is not supported. This change will enhance in version
> > number returned.
> >
> > Current version info returned won't be able to be recognized
> > by Linux VF driver, change to values that both DPDK VF and Linux
> > driver can recognize.
> >
> > The expense is original DPDK host specific feature like
> > CFG_VLAN_PVID and CONFIG_VSI_QUEUES_EXT will not available.
> >
> > DPDK VF also can't identify host driver by version number returned.
> > It always assume talking with Linux PF.
>
> I guess you mention from following code [1], should it be also updated
> to prevent it giving wrong information:
I'd like to update it into some docs.
>
> [1] i40e_ethdev_vf.c
> if (vf->version_major == I40E_DPDK_VERSION_MAJOR)
> PMD_DRV_LOG(INFO, "Peer is DPDK PF host");
> else if ((vf->version_major == I40E_VIRTCHNL_VERSION_MAJOR) &&
> (vf->version_minor <= I40E_VIRTCHNL_VERSION_MINOR))
> PMD_DRV_LOG(INFO, "Peer is Linux PF host");
> else {
>
> >
> > Signed-off-by: Chen Jing D(Mark)
> > ---
>
> <...>
Re: [dpdk-dev] [PATCH v2 15/32] net/i40e: add VF vlan strip func
HI, Ferruh,
Best Regards,
Mark
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, December 07, 2016 10:18 PM
> To: Lu, Wenzhuo ; dev@dpdk.org
> Cc: Chen, Jing D
> Subject: Re: [dpdk-dev] [PATCH v2 15/32] net/i40e: add VF vlan strip func
>
> On 12/7/2016 3:31 AM, Wenzhuo Lu wrote:
> > Add a function to configure vlan strip enable/disable for specific
> > SRIOV VF device.
> >
> > Signed-off-by: Chen Jing D(Mark)
> > ---
>
> <...>
>
> > +
> > +/* Set vlan strip on/off for specific VF from host */
> > +int
> > +rte_pmd_i40e_set_vf_vlan_stripq(uint8_t port, uint16_t vf_id, uint8_t on)
> > +{
> > + struct rte_eth_dev *dev;
> > + struct i40e_pf *pf;
> > + struct i40e_vsi *vsi;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port];
> > + pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> > +
> > + if (vf_id > pf->vf_num - 1 || !pf->vfs) {
> > + PMD_DRV_LOG(ERR, "Invalid argument.");
> > + return -EINVAL;
> > + }
> > +
> > + vsi = pf->vfs[vf_id].vsi;
> > +
> > + if (vsi)
> > + return i40e_vsi_config_vlan_stripping(vsi, !!on);
> > + else
>
> if vd_if is valid, can vsi be NULL? If so this check may be required in
> some prev patches too.
It's a little impossible. This sanity check just make the code stronger.
>
> > + return -EINVAL;
> > +}
> > diff --git a/drivers/net/i40e/rte_pmd_i40e.h
> > b/drivers/net/i40e/rte_pmd_i40e.h
> > index ca5e05a..043ae62 100644
> > --- a/drivers/net/i40e/rte_pmd_i40e.h
> > +++ b/drivers/net/i40e/rte_pmd_i40e.h
> > @@ -187,4 +187,24 @@ int rte_pmd_i40e_set_vf_multicast_promisc(uint8_t port,
> > int rte_pmd_i40e_set_vf_mac_addr(uint8_t port, uint16_t vf_id,
> > struct ether_addr *mac_addr);
> >
> > +/**
> > + * Enable/Disable vf vlan strip for all queues in a pool
> > + *
> > + * @param port
> > + *The port identifier of the Ethernet device.
> > + * @param vf
> > + *ID specifying VF.
> > + * @param on
> > + *1 - Enable VF's vlan strip on RX queues.
> > + *0 - Disable VF's vlan strip on RX queues.
> > + *
> > + * @return
> > + * - (0) if successful.
> > + * - (-ENOTSUP) if hardware doesn't support this feature.
>
> Is this error type returned?
Good catch. Only -EINVAL and -ENODEV would be returned.
>
> > + * - (-ENODEV) if *port* invalid.
> > + * - (-EINVAL) if bad parameter.
> > + */
> <...>
Re: [dpdk-dev] [PATCH v2 28/32] net/i40e: return correct vsi_id
Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Wednesday, December 7, 2016 11:16 PM > To: Lu, Wenzhuo ; dev@dpdk.org > Cc: Chen, Jing D > Subject: Re: [dpdk-dev] [PATCH v2 28/32] net/i40e: return correct vsi_id > > On 12/7/2016 3:32 AM, Wenzhuo Lu wrote: > > PF host didn't return correct VSI id to VF. > > This change fix it. > > This looks like a fix for current code, > can you please update commit title and log to reflect the fix? > This is similar patch to support Linux VF client. DPDK VF client needn't Vsi ID. > > > > Signed-off-by: Chen Jing D(Mark) > > --- > > drivers/net/i40e/i40e_pf.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c > > index 0f582ed..8319c2c 100644 > > --- a/drivers/net/i40e/i40e_pf.c > > +++ b/drivers/net/i40e/i40e_pf.c > > @@ -351,8 +351,7 @@ > > > > /* Change below setting if PF host can support more VSIs for VF */ > > vf_res->vsi_res[0].vsi_type = I40E_VSI_SRIOV; > > - /* As assume Vf only has single VSI now, always return 0 */ > > - vf_res->vsi_res[0].vsi_id = 0; > > + vf_res->vsi_res[0].vsi_id = vf->vsi->vsi_id; > > vf_res->vsi_res[0].num_queue_pairs = vf->vsi->nb_qps; > > ether_addr_copy(&vf->mac_addr, > > (struct ether_addr *)vf_res->vsi_res[0].default_mac_addr); > >
Re: [dpdk-dev] [PATCH v2 29/32] net/i40e: parse more VF parameter and configure
Hi, Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Wednesday, December 7, 2016 11:19 PM > To: Lu, Wenzhuo ; dev@dpdk.org > Cc: Chen, Jing D > Subject: Re: [dpdk-dev] [PATCH v2 29/32] net/i40e: parse more VF parameter > and configure > > On 12/7/2016 3:32 AM, Wenzhuo Lu wrote: > > When VF requested to configure TX queue, a few parameters are missed > > to be configured in PF host. This change have more fields parsed and > > configured for TX context. > > What is the effect of missing Tx paramters configured? > > If this cause a bug, this patch should be a fix. > This need to analyze case by case. If PF driver is serving a DPDK VF client, the missing part is OK. If serving a Linux VF client, the missing part will cause some unexpected TX queue behaviors. So, this is an enhancement to support Linux VF client. > > > > Signed-off-by: Chen Jing D(Mark) > > --- > > drivers/net/i40e/i40e_pf.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c > > index 8319c2c..1ad5ed1 100644 > > --- a/drivers/net/i40e/i40e_pf.c > > +++ b/drivers/net/i40e/i40e_pf.c > > @@ -422,10 +422,12 @@ > > > > /* clear the context structure first */ > > memset(&tx_ctx, 0, sizeof(tx_ctx)); > > - tx_ctx.new_context = 1; > > tx_ctx.base = txq->dma_ring_addr / I40E_QUEUE_BASE_ADDR_UNIT; > > tx_ctx.qlen = txq->ring_len; > > tx_ctx.rdylist = rte_le_to_cpu_16(vf->vsi->info.qs_handle[0]); > > + tx_ctx.head_wb_ena = txq->headwb_enabled; > > + tx_ctx.head_wb_addr = txq->dma_headwb_addr; > > + > > err = i40e_clear_lan_tx_queue_context(hw, abs_queue_id); > > if (err != I40E_SUCCESS) > > return err; > >
[dpdk-dev] [PATCH 0/3] net: fix out of order rx read issue
Hi, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qi Zhang > Sent: Monday, October 17, 2016 1:24 AM > To: Wu, Jingjing ; Zhang, Helin > > Cc: dev at dpdk.org; Zhang, Qi Z > Subject: [dpdk-dev] [PATCH 0/3] net: fix out of order rx read issue > > Volatile point has been cast to non-volatile point when call _mm_loadu_si128, > so add compile barrier to prevent compiler reorder. > > Qi Zhang (3): > net/i40e: fix out of order rx read issue > net/ixgbe: fix out of order rx read issue > net/fm10k: fix out of order rx read issue > > drivers/net/fm10k/fm10k_rxtx_vec.c | 3 +++ > drivers/net/i40e/i40e_rxtx_vec.c | 3 +++ > drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 3 +++ > 3 files changed, 9 insertions(+) I have an overall comment on the committed message. You'd better to describe why we have out of order issue here and the requirement on the execution order of the 4 loads.
[dpdk-dev] [PATCH v4 2/2] i40e: Enable bad checksum flags in i40e vPMD
> -Original Message- > From: Shaw, Jeffrey B > Sent: Wednesday, October 5, 2016 11:38 PM > To: dev at dpdk.org > Cc: Zhang, Helin ; Wu, Jingjing > ; damarion at cisco.com; Zhang, Qi Z > ; Chen, Jing D > Subject: [PATCH v4 2/2] i40e: Enable bad checksum flags in i40e vPMD > > From: Damjan Marion > > Decode the checksum flags from the rx descriptor, setting the appropriate bit > in the mbuf ol_flags field when the flag indicates a bad checksum. > > Signed-off-by: Damjan Marion > Signed-off-by: Jeff Shaw Acked-by: Jing Chen
[dpdk-dev] [PATCH v4 1/2] i40e: Add packet_type metadata in the i40e vPMD
> -Original Message- > From: Shaw, Jeffrey B > Sent: Wednesday, October 5, 2016 11:38 PM > To: dev at dpdk.org > Cc: Zhang, Helin ; Wu, Jingjing > ; damarion at cisco.com; Zhang, Qi Z > ; Chen, Jing D > Subject: [PATCH v4 1/2] i40e: Add packet_type metadata in the i40e vPMD > > From: Damjan Marion > > The ptype is decoded from the rx descriptor and stored in the packet type > field in the mbuf using the same function as the non-vector driver. > > Signed-off-by: Damjan Marion > Signed-off-by: Jeff Shaw > Acked-by: Qi Zhang > --- > > Changes in v2: > - Add missing reference to i40e_recv_scattered_pkts_vec() when >querying supported packet types. > > Changes in v3: > - None. (Please ignore this version). > > Changes in v4: > - Fix rss/fdir status mask and shift to get accurate Flow Director Filter >Match (FLM) indication. > > drivers/net/i40e/i40e_rxtx.c | 567 > +-- > drivers/net/i40e/i40e_rxtx.h | 563 > ++ > drivers/net/i40e/i40e_rxtx_vec.c | 16 ++ > 3 files changed, 582 insertions(+), 564 deletions(-) Acked-by : Jing Chen
[dpdk-dev] [PATCH v2 2/2] i40e: Enable bad checksum flags in i40e vPMD
Hi,
> -Original Message-
> From: Shaw, Jeffrey B
> Sent: Wednesday, October 5, 2016 5:13 PM
> To: dev at dpdk.org
> Cc: Zhang, Helin ; Wu, Jingjing
> ; damarion at cisco.com; Zhang, Qi Z
> ; Chen, Jing D
> Subject: [PATCH v2 2/2] i40e: Enable bad checksum flags in i40e vPMD
>
> From: Damjan Marion
>
> Decode the checksum flags from the rx descriptor, setting the appropriate bit
> in the mbuf ol_flags field when the flag indicates a bad checksum.
>
> Signed-off-by: Damjan Marion
> Signed-off-by: Jeff Shaw
> ---
> drivers/net/i40e/i40e_rxtx_vec.c | 48 +++---
> --
> 1 file changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx_vec.c
> b/drivers/net/i40e/i40e_rxtx_vec.c
> index 6c63141..d2267ad 100644
> --- a/drivers/net/i40e/i40e_rxtx_vec.c
> +++ b/drivers/net/i40e/i40e_rxtx_vec.c
> @@ -138,19 +138,14 @@ i40e_rxq_rearm(struct i40e_rx_queue *rxq) static
> inline void desc_to_olflags_v(__m128i descs[4], struct rte_mbuf **rx_pkts) {
> - __m128i vlan0, vlan1, rss;
> - union {
> - uint16_t e[4];
> - uint64_t dword;
> - } vol;
> + __m128i vlan0, vlan1, rss, l3_l4e;
>
> /* mask everything except RSS, flow director and VLAN flags
>* bit2 is for VLAN tag, bit11 for flow director indication
>* bit13:12 for RSS indication.
>*/
> - const __m128i rss_vlan_msk = _mm_set_epi16(
> - 0x, 0x, 0x, 0x,
> - 0x3804, 0x3804, 0x3804, 0x3804);
> + const __m128i rss_vlan_msk = _mm_set_epi32(
> + 0x1c03004, 0x1c03004, 0x1c03004, 0x1c03004);
>
> /* map rss and vlan type to rss hash and vlan flag */
> const __m128i vlan_flags = _mm_set_epi8(0, 0, 0, 0, @@ -163,23
> +158,36 @@ desc_to_olflags_v(__m128i descs[4], struct rte_mbuf **rx_pkts)
> PKT_RX_RSS_HASH | PKT_RX_FDIR,
> PKT_RX_RSS_HASH, 0, 0,
> 0, 0, PKT_RX_FDIR, 0);
>
> - vlan0 = _mm_unpackhi_epi16(descs[0], descs[1]);
> - vlan1 = _mm_unpackhi_epi16(descs[2], descs[3]);
> - vlan0 = _mm_unpacklo_epi32(vlan0, vlan1);
> + const __m128i l3_l4e_flags = _mm_set_epi8(0, 0, 0, 0, 0, 0, 0, 0,
> + PKT_RX_EIP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD
> | PKT_RX_IP_CKSUM_BAD,
> + PKT_RX_EIP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD,
> + PKT_RX_EIP_CKSUM_BAD | PKT_RX_IP_CKSUM_BAD,
> + PKT_RX_EIP_CKSUM_BAD,
> + PKT_RX_L4_CKSUM_BAD | PKT_RX_IP_CKSUM_BAD,
> + PKT_RX_L4_CKSUM_BAD,
> + PKT_RX_IP_CKSUM_BAD,
> + 0);
> +
> + vlan0 = _mm_unpackhi_epi32(descs[0], descs[1]);
> + vlan1 = _mm_unpackhi_epi32(descs[2], descs[3]);
> + vlan0 = _mm_unpacklo_epi64(vlan0, vlan1);
>
> vlan1 = _mm_and_si128(vlan0, rss_vlan_msk);
> vlan0 = _mm_shuffle_epi8(vlan_flags, vlan1);
>
> - rss = _mm_srli_epi16(vlan1, 11);
> + rss = _mm_srli_epi32(vlan1, 12);
> rss = _mm_shuffle_epi8(rss_flags, rss);
My bad. Original code will use bit[13:11] to identify RSS and FDIR flag. Now
It masked bit 11 out when creating " rss_vlan_msk" and doing shift above,
while it still try to use original "rss_flags"?
[dpdk-dev] [PATCH v2 2/2] i40e: Enable bad checksum flags in i40e vPMD
Hi, > -Original Message- > From: Shaw, Jeffrey B > Sent: Wednesday, October 5, 2016 5:13 PM > To: dev at dpdk.org > Cc: Zhang, Helin ; Wu, Jingjing > ; damarion at cisco.com; Zhang, Qi Z > ; Chen, Jing D > Subject: [PATCH v2 2/2] i40e: Enable bad checksum flags in i40e vPMD > > From: Damjan Marion > > Decode the checksum flags from the rx descriptor, setting the appropriate bit > in the mbuf ol_flags field when the flag indicates a bad checksum. > > Signed-off-by: Damjan Marion > Signed-off-by: Jeff Shaw Acked-by: Jing Chen It seems this patch also fixed a vlan flag bug, should it explain a little bit?
[dpdk-dev] [PATCH v2 1/2] i40e: Add packet_type metadata in the i40e vPMD
Hi, > -Original Message- > From: Shaw, Jeffrey B > Sent: Wednesday, October 5, 2016 5:13 PM > To: dev at dpdk.org > Cc: Zhang, Helin ; Wu, Jingjing > ; damarion at cisco.com; Zhang, Qi Z > ; Chen, Jing D > Subject: [PATCH v2 1/2] i40e: Add packet_type metadata in the i40e vPMD > > From: Damjan Marion > > The ptype is decoded from the rx descriptor and stored in the packet type > field in the mbuf using the same function as the non-vector driver. > > Signed-off-by: Damjan Marion > Signed-off-by: Jeff Shaw > Acked-by: Qi Zhang > --- > > Changes in v2: > - Add missing reference to i40e_recv_scattered_pkts_vec() when >querying supported packet types. > > drivers/net/i40e/i40e_rxtx.c | 567 > +-- > drivers/net/i40e/i40e_rxtx.h | 563 > ++ > drivers/net/i40e/i40e_rxtx_vec.c | 16 ++ > 3 files changed, 582 insertions(+), 564 deletions(-) > Acked-by: Jing Chen
[dpdk-dev] [PATCH 1/2] i40e: Add packet_type metadata in the i40e vPMD
Hi, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jeff Shaw > Sent: Thursday, July 14, 2016 9:59 AM > To: dev at dpdk.org; Zhang, Helin ; Wu, Jingjing > ; damarion at cisco.com > Subject: [dpdk-dev] [PATCH 1/2] i40e: Add packet_type metadata in the i40e > vPMD > > From: Damjan Marion > > The ptype is decoded from the rx descriptor and stored in the packet type > field in the mbuf using the same function as the non-vector driver. > > Signed-off-by: Damjan Marion > Signed-off-by: Jeff Shaw > --- > drivers/net/i40e/i40e_rxtx.c | 566 > +-- > drivers/net/i40e/i40e_rxtx.h | 563 > ++ > drivers/net/i40e/i40e_rxtx_vec.c | 16 ++ > 3 files changed, 581 insertions(+), 564 deletions(-) > > - > #define I40E_RX_DESC_EXT_STATUS_FLEXBH_MASK 0x03 > #define I40E_RX_DESC_EXT_STATUS_FLEXBH_FD_ID 0x01 > #define I40E_RX_DESC_EXT_STATUS_FLEXBH_FLEX 0x02 > @@ -2136,7 +1573,8 @@ i40e_dev_supported_ptypes_get(struct rte_eth_dev > *dev) #ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC > dev->rx_pkt_burst == i40e_recv_pkts_bulk_alloc || #endif > - dev->rx_pkt_burst == i40e_recv_scattered_pkts) > + dev->rx_pkt_burst == i40e_recv_scattered_pkts || > + dev->rx_pkt_burst == i40e_recv_pkts_vec) Missed i40e_recv_scattered_pkts_vec()?
[dpdk-dev] [PATCH v3] net: fix build error with clang
Hi,
> -Original Message-
> From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com]
> Sent: Tuesday, September 27, 2016 5:20 AM
> To: dev at dpdk.org
> Cc: Jerin Jacob ; Chen, Jing D
> ; Liang, Cunming ;
> Richardson, Bruce ; Thomas Monjalon
>
> Subject: Re: [PATCH v3] net: fix build error with clang
>
> Can any PMD guys review it? It blocks a virtio patchset apply...
>
> Thanks.
>
> --yliu
>
> On Mon, Sep 26, 2016 at 12:29:13PM +0800, Yuanhan Liu wrote:
> > Interestingly, clang and gcc has different prototype for _mm_prefetch().
> > For gcc, we have
> >
> >_mm_prefetch (const void *__P, enum _mm_hint __I)
> >
> > While for clang, it's
> >
> >#define _mm_prefetch(a, sel) (__builtin_prefetch((void *)(a), 0,
> > (sel)))
> >
> > That's how the following error comes with clang:
> >
> >error: cast from 'const void *' to 'void *' drops const qualifier
> >[-Werror,-Wcast-qual]
> >_mm_prefetch((const void *)rused, _MM_HINT_T0);
> >/usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include/xmmintrin.h:684:58:
> >note: expanded from macro '_mm_prefetch'
> > #define _mm_prefetch(a, sel) (__builtin_prefetch((void *)(a),
> > 0, (sel)))
> >
> > What's weird is that the build was actaully Okay before. I met it
> > while apply Jerin's vector support for ARM patch set: he just move
> > this peiece of code to another file, nothing else changed.
> >
> > This patch fix the issue when Jerin's patchset is applied. Thus, I
> > think it's still needed.
> >
> > Similarly, make the same change to other _mm_prefetch users, just in
> > case this weird issue shows up again somehow later.
> >
> > Fixes: fc3d66212fed ("virtio: add vector Rx")
> > Fixes: c95584dc2b18 ("ixgbe: new vectorized functions for Rx/Tx")
> > Fixes: 9ed94e5bb04e ("i40e: add vector Rx")
> > Fixes: 7092be8437bd ("fm10k: add vector Rx")
> >
> > Cc: Jerin Jacob
> > Cc: Chen Jing D(Mark)
> > Cc: Cunming Liang
> > Cc: Bruce Richardson
> > CC: Thomas Monjalon
> > Signed-off-by: Yuanhan Liu
Acked-by: Jing Chen
[dpdk-dev] [PATCH v2 0/5] implement new Rx checksum flag
Hi, > -Original Message- > From: Wang, Xiao W > Sent: Tuesday, September 06, 2016 9:27 AM > To: dev at dpdk.org > Cc: Chen, Jing D ; olivier.matz at 6wind.com; Wang, > Xiao W > > Subject: [PATCH v2 0/5] implement new Rx checksum flag > > v2: > * Removed hw_ip_checksum check in fm10k_rx_vec_condition_check(). > > * Defined CKSUM_SHIFT for SSE bits shift. > > * Changed commit title from "add back Rx checksum offload" to > "fix Rx checksum flags". > > * Added new cksum flag support for ixgbe vector Rx, based on patch > (http://dpdk.org/dev/patchwork/patch/14630/) which came earlier. > > v1: > Following http://dpdk.org/dev/patchwork/patch/14941/, this patch set > implements newly defined Rx checksum flag for igb, ixgbe, i40e and fm10k. > > Currently, ixgbe and fm10k support Rx checksum offload in both scalar > and vector datapath, while the other two don't, this patch set keeps > this situation. > > Note: This patch set has dependency on the following patches: > > "mbuf: add new Rx checksum mbuf flags" > (http://dpdk.org/dev/patchwork/patch/14941/) > > "ixgbe: support checksum flags in sse vector Rx function" > (http://dpdk.org/dev/patchwork/patch/14630/) > > Xiao Wang (5): > net/fm10k: fix Rx checksum flags > net/fm10k: implement new Rx checksum flag > net/e1000: implement new Rx checksum flag > net/ixgbe: implement new Rx checksum flag > net/i40e: implement new Rx checksum flag > > drivers/net/e1000/igb_rxtx.c | 4 +++- > drivers/net/fm10k/fm10k_rxtx.c | 14 ++ > drivers/net/fm10k/fm10k_rxtx_vec.c | 24 +--- > drivers/net/i40e/i40e_rxtx.c | 6 ++ > drivers/net/ixgbe/ixgbe_rxtx.c | 4 +++- > drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 30 -- > 6 files changed, 67 insertions(+), 15 deletions(-) Acked-by : Jing Chen
[dpdk-dev] [PATCH 2/5] net/fm10k: implement new Rx checksum flag
Hi, > uint16_t > diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c > b/drivers/net/fm10k/fm10k_rxtx_vec.c > index 9ea747e..8c08b44 100644 > --- a/drivers/net/fm10k/fm10k_rxtx_vec.c > +++ b/drivers/net/fm10k/fm10k_rxtx_vec.c > @@ -95,8 +95,10 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf > **rx_pkts) > const __m128i l3l4cksum_flag = _mm_set_epi8(0, 0, 0, 0, > 0, 0, 0, 0, > 0, 0, 0, 0, > - PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD, > - PKT_RX_IP_CKSUM_BAD, PKT_RX_L4_CKSUM_BAD, 0); > + (PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD) >> 1, > + (PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_GOOD) >> > 1, > + (PKT_RX_IP_CKSUM_GOOD | PKT_RX_L4_CKSUM_BAD) >> > 1, > + (PKT_RX_IP_CKSUM_GOOD | > PKT_RX_L4_CKSUM_GOOD) >> 1); Can we define a macro, like "#define RTE_CKSUM_SHIFT 1" to avoid numeric? > > const __m128i rxe_flag = _mm_set_epi8(0, 0, 0, 0, > 0, 0, 0, 0, > @@ -139,6 +141,7 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct > rte_mbuf **rx_pkts) > /* Process L4/L3 checksum error flags */ > cksumflag = _mm_srli_epi16(cksumflag, L3L4EFLAG_SHIFT); > cksumflag = _mm_shuffle_epi8(l3l4cksum_flag, cksumflag); > + cksumflag = _mm_slli_epi16(cksumflag, 1); > vtag1 = _mm_or_si128(cksumflag, vtag1); > > vol.dword = _mm_cvtsi128_si64(vtag1); > -- > 1.9.3 Besides that, just realize we should remove "hw_ip_checksum" check in func fm10k_rx_vec_condition_check() since we already support it. Can you help to make the change?
[dpdk-dev] [PATCH] net/fm10k: fix MAC address remnant in switch
Hi,
> -Original Message-
> From: Wang, Xiao W
> Sent: Friday, August 05, 2016 11:18 AM
> To: Chen, Jing D ; Lin, Xueqin intel.com>
> Cc: dev at dpdk.org; Wang, Xiao W
> Subject: [PATCH] net/fm10k: fix MAC address remnant in switch
>
> When testpmd quits with two ports, the second port's MAC address
> remains in the MAC table of switch manager.
>
> There should be some time for HW to quiesce when closing a port,
> otherwise the subsequent port close won't be handled correctly.
>
> This patch adds some delay after turning off a logic port, just as
> what the kernel driver does.
>
> Fixes: 8b5c9ec20b7b ("support VMDQ in MAC/VLAN filter")
>
> Reported-by: Xueqin Lin
> Signed-off-by: Xiao Wang
Acked-by : Jing Chen
[dpdk-dev] [PATCH] net/fm10k: fix RSS hash config
Hi, Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, July 22, 2016 4:29 PM > To: Chen, Jing D > Cc: dev at dpdk.org; Wang, Xiao W ; Lin, Xueqin > > Subject: Re: [dpdk-dev] [PATCH] net/fm10k: fix RSS hash config > > 2016-07-22 08:23, Chen, Jing D: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2016-07-21 09:35, Wang, Xiao W: > > > > From: Chen, Jing D > > > > > > --- a/drivers/net/fm10k/fm10k_ethdev.c > > > > > > +++ b/drivers/net/fm10k/fm10k_ethdev.c > > > > > > @@ -2159,8 +2159,8 @@ fm10k_rss_hash_update(struct rte_eth_dev > *dev, > > > > > > > > > > > > PMD_INIT_FUNC_TRACE(); > > > > > > > > > > > > - if (rss_conf->rss_key_len < FM10K_RSSRK_SIZE * > > > > > > - FM10K_RSSRK_ENTRIES_PER_REG) > > > > > > + if (key && (rss_conf->rss_key_len < FM10K_RSSRK_SIZE * > > > > > > + FM10K_RSSRK_ENTRIES_PER_REG)) > > > > > > return -EINVAL; > > > > > > > > > > > > if (hf == 0) > > > > > > > > > > It's also possible that app wants to update rss key and not expect to > > > > > update > hash > > > > > function. > > > > > Is that indicate we shouldn't return error in case hf == 0? > > > > > > > > > > > > > If the app just wants to update RSS key, it needs to read out the RSS > > > > config first, > > > then > > > > change only the key field. This is what testpmd does for this operation. > > > > > > > > hf == 0 will disable RSS feature, I think we should return error to > > > > protect > multi- > > > queue. > > > > > > Jing, do you confirm we can apply this patch, please? > > I think we need some rework or more explanations here. > > It is not reasonnable to wait RC5 for such a fix. > Either it is not important and postponed to 16.11 or you submit > a v2 very shortly for 16.07. > Please advise Please kindly merge.
[dpdk-dev] [PATCH] net/fm10k: fix RSS hash config
Hi, Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, July 22, 2016 4:22 PM > To: Chen, Jing D > Cc: dev at dpdk.org; Wang, Xiao W ; Lin, Xueqin > > Subject: Re: [dpdk-dev] [PATCH] net/fm10k: fix RSS hash config > > 2016-07-21 09:35, Wang, Xiao W: > > From: Chen, Jing D > > > > --- a/drivers/net/fm10k/fm10k_ethdev.c > > > > +++ b/drivers/net/fm10k/fm10k_ethdev.c > > > > @@ -2159,8 +2159,8 @@ fm10k_rss_hash_update(struct rte_eth_dev *dev, > > > > > > > > PMD_INIT_FUNC_TRACE(); > > > > > > > > - if (rss_conf->rss_key_len < FM10K_RSSRK_SIZE * > > > > - FM10K_RSSRK_ENTRIES_PER_REG) > > > > + if (key && (rss_conf->rss_key_len < FM10K_RSSRK_SIZE * > > > > + FM10K_RSSRK_ENTRIES_PER_REG)) > > > > return -EINVAL; > > > > > > > > if (hf == 0) > > > > > > It's also possible that app wants to update rss key and not expect to > > > update hash > > > function. > > > Is that indicate we shouldn't return error in case hf == 0? > > > > > > > If the app just wants to update RSS key, it needs to read out the RSS > > config first, > then > > change only the key field. This is what testpmd does for this operation. > > > > hf == 0 will disable RSS feature, I think we should return error to protect > > multi- > queue. > > Jing, do you confirm we can apply this patch, please? I think we need some rework or more explanations here.
[dpdk-dev] [PATCH] net/fm10k: fix RSS hash config
Hi, > diff --git a/drivers/net/fm10k/fm10k_ethdev.c > b/drivers/net/fm10k/fm10k_ethdev.c > index 144b2de..01f4a72 100644 > --- a/drivers/net/fm10k/fm10k_ethdev.c > +++ b/drivers/net/fm10k/fm10k_ethdev.c > @@ -2159,8 +2159,8 @@ fm10k_rss_hash_update(struct rte_eth_dev *dev, > > PMD_INIT_FUNC_TRACE(); > > - if (rss_conf->rss_key_len < FM10K_RSSRK_SIZE * > - FM10K_RSSRK_ENTRIES_PER_REG) > + if (key && (rss_conf->rss_key_len < FM10K_RSSRK_SIZE * > + FM10K_RSSRK_ENTRIES_PER_REG)) > return -EINVAL; > > if (hf == 0) It's also possible that app wants to update rss key and not expect to update hash function. Is that indicate we shouldn't return error in case hf == 0?
[dpdk-dev] [PATCH] net/i40e: revert VLAN filtering fix
Hi,
> -Original Message-
> From: Wu, Jingjing
> Sent: Wednesday, July 13, 2016 6:28 PM
> To: Richardson, Bruce
> Cc: dev at dpdk.org; Wu, Jingjing ; Shaw, Jeffrey B
> ; Zhang, Helin ; Chen,
> Jing D ; Ananyev, Konstantin
>
> Subject: [PATCH] net/i40e: revert VLAN filtering fix
>
> This reverts commit 4761f57d58c6f52543738dbe299f846d62d75895.
> Introducing VLAN table by adding VLAN adminq command will cause NIC's
> throughput drop obviously. It's a hardware issue.
> With this revert, VLAN filtering can only work when promiscuous mode is
> disabled.
>
> Reverts: 4761f57d58c6 ("net/i40e: fix VLAN filtering in promiscuous mode")
>
> Reported-by: Jeffrey Shaw
> Signed-off-by: Jingjing Wu
Acked-by : Jing Chen
[dpdk-dev] [PATCH] fm10k: fix VF cannot receive broadcast traffic
Hi, Bruce,
> -Original Message-
> From: Richardson, Bruce
> Sent: Friday, June 17, 2016 6:19 PM
> To: Wang, Xiao W
> Cc: Chen, Jing D ; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] fm10k: fix VF cannot receive broadcast
> traffic
>
> On Mon, Jun 06, 2016 at 05:00:47PM +0800, Wang Xiao W wrote:
> > When app tries promisc/allmulti setting, fm10k will check if a valid
> > glort is acquired, if not then exit without doing anything. It's a
> > long journey for VF to acquire glort info from VF to PF mailbox, PF to
> > switch
> mailbox.
> > It could be a long interval that's out of DPDK's control. Thus, app
> > may
>
> I think the use of "thus" here is wrong, as I suspect that the failure is not
> due
> to the "long interval that's out of DPDK's control", but instead due to not
> having a valid glort.
The logic in VF is glort ID is invalid at beginning. When VF port is enabled by
sending mailbox to PF, PF will send a message back to VF without carrying valid
info. Then, VF will fake a glort ID.
In this case, it's useless to do sanity check of VALID glort ID. Besides that,
VF didn't
use glort ID to do functional call at all.
>
> > fail on promisc/allmulti setting in VF. In fact, we don't need a valid
> > glort value in VF, so this patch just skips the glort check for VF.
> >
> > Fixes: df02ba864695 ("fm10k: support promiscuous mode")
> >
> > Signed-off-by: Wang Xiao W
>
> I rework this commit message for you on apply. Please check the updated
> version when done.
>
> /Bruce
[dpdk-dev] [PATCH] fm10k: fix VF cannot receive broadcast traffic
Hi,
> -Original Message-
> From: Wang, Xiao W
> Sent: Monday, June 06, 2016 5:01 PM
> To: Chen, Jing D
> Cc: dev at dpdk.org; Wang, Xiao W
> Subject: [PATCH] fm10k: fix VF cannot receive broadcast traffic
>
> When app tries promisc/allmulti setting, fm10k will check if a valid glort
> is acquired, if not then exit without doing anything. It's a long journey
> for VF to acquire glort info from VF to PF mailbox, PF to switch mailbox.
> It could be a long interval that's out of DPDK's control. Thus, app may
> fail on promisc/allmulti setting in VF. In fact, we don't need a valid
> glort value in VF, so this patch just skips the glort check for VF.
>
> Fixes: df02ba864695 ("fm10k: support promiscuous mode")
>
> Signed-off-by: Wang Xiao W
Acked-by: Jing Chen
[dpdk-dev] [PATCH] doc: remove reference to MATCH
From: "Chen Jing D(Mark)" Intel stopped supporting MATCH, remove reference of MATCH in the document. Signed-off-by: Chen Jing D(Mark) --- doc/guides/nics/fm10k.rst |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst index c4915d8..7fc4862 100644 --- a/doc/guides/nics/fm10k.rst +++ b/doc/guides/nics/fm10k.rst @@ -157,10 +157,9 @@ Switch manager The Intel FM1 family of NICs integrate a hardware switch and multiple host interfaces. The FM1 PMD driver only manages host interfaces. For the switch component another switch driver has to be loaded prior to to the -FM1 PMD driver. The switch driver can be acquired for Intel support or -from the `Match Interface <https://github.com/match-interface>`_ project. +FM1 PMD driver. The switch driver can be acquired from Intel support. Only Testpoint is validated with DPDK, the latest version that has been -validated with DPDK2.2 is 4.1.6. +validated with DPDK is 4.1.6. CRC striping -- 1.7.7.6
[dpdk-dev] [PATCH v2] fm10k: set packet type for multi-segment packets
Hi,
> -Original Message-
> From: Michael Frasca [mailto:michael.frasca at oracle.com]
> Sent: Monday, April 18, 2016 8:52 PM
> To: Chen, Jing D
> Cc: dev at dpdk.org; Michael Frasca
> Subject: [PATCH v2] fm10k: set packet type for multi-segment packets
>
> When building a chain of mbufs for a multi-segment packet, the packet_type
> field resides at the end of the chain. It should be copied forward to the head
> of the list.
>
> Also, uses RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE to guard packet-type
> computation. The mbuf fields are not copied when this define is not set.
>
> Fixes: fe65e1e1ce61 ("fm10k: add vector scatter Rx")
>
> Signed-off-by: Michael Frasca
Acked-by : Jing Chen
[dpdk-dev] [PATCH] fm10k: set packet type for multi-segment packets
Hi, Frasca,
> -Original Message-
> From: Michael Frasca [mailto:michael.frasca at oracle.com]
> Sent: Friday, April 15, 2016 3:32 AM
> To: Chen, Jing D
> Cc: dev at dpdk.org; Michael Frasca
> Subject: [PATCH] fm10k: set packet type for multi-segment packets
>
> When building a chain of mbufs for a multi-segment packet, the
> packet_type field resides at the end of the chain. It should be
> copied forward to the head of the list.
>
> Fixes: fe65e1e1ce61 ("fm10k: add vector scatter Rx")
>
> Signed-off-by: Michael Frasca
> ---
> drivers/net/fm10k/fm10k_rxtx_vec.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
> b/drivers/net/fm10k/fm10k_rxtx_vec.c
> index f8efe8f..66f126f 100644
> --- a/drivers/net/fm10k/fm10k_rxtx_vec.c
> +++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
> @@ -608,6 +608,7 @@ fm10k_reassemble_packets(struct fm10k_rx_queue
> *rxq,
> /* it's the last packet of the set */
> start->hash = end->hash;
> start->ol_flags = end->ol_flags;
> + start->packet_type = end->packet_type;
> pkts[pkt_idx++] = start;
> start = end = NULL;
> }
> --
> 2.5.0
Good catch. Just one comment. We'll parse packet type until
"RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE" is applied. Can we add this macro for
your change? Same to "hash" and "olf_flags".
Best Regards,
Mark
[dpdk-dev] [PATCH v3] doc: update nic overview
From: "Chen Jing D(Mark)" Add feature support list for fm10k, fm10k-vec, fm10kvf and fm10kvf-vec. Signed-off-by: Chen Jing D(Mark) --- v3: - rebase to latest repo - Add a few feature set that fm10k support v2: - fix a typo doc/guides/nics/overview.rst | 106 +- 1 files changed, 53 insertions(+), 53 deletions(-) diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst index 05f7f72..5208a6c 100644 --- a/doc/guides/nics/overview.rst +++ b/doc/guides/nics/overview.rst @@ -74,76 +74,76 @@ Most of these differences are summarized below. .. table:: Features availability in networking drivers - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - Feature a b b b c e e e i i i i i i i i i i f f m m m n n p r s v v v v x -f n n o x 1 n n 4 4 4 4 g g x x x x m m l l p f u c i z h i i m e -p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 x x i p l a n e o r r x n -a 2 2 d b 0 c e e e e v b b b b 0 0 4 5 p l p g d s t t n v -c x x i e 0 . v v f e e e e k k e a t i i e i -k v n . f f . v v . t o o t r -e f g . . . f f . a . 3 t -t v v v v v 2 v - e e e e e e - c c c c c c - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = + = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = + Feature a b b b c e e e i i i i i i i i i i f f f f m m m n n p r s v v v v x +f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f u c i z h i i m e +p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p l a n e o r r x n +a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p l p g d s t t n v +c x x i e 0 . v v f e e e e k k k k e a t i i e i +k v n . f f . v v . v v t o o t r +e f g . . . f f . f f a . 3 t +t v v v v v v 2 v + e e e e e e e + c c c c c c c + = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = speed capabilities - link status X X X X X X X X X X X X X X X X - link status event X X X X X X X X X - queue status event X - Rx interrupt X X X X X X X X X X X - queue start/stop X X X X X X X X X X X X X X - MTU update X X X X X X X X X X - jumbo frame X X X X X X X X X X X X X X X - scattered Rx X X X X X X X X X X X X X X X X X + link status X X X X X X X X X X X X X X X X + link status event X X X X X X X X X + queue status event X + Rx interrupt X X X X X X X X X X X X X X X + queue start/stop X X X X X X X X X X X X X X X X X X + MTU update X X X X X X X X X X + jumbo frame X X X X X X X X X X X X X X X X X X X + scattered Rx X X X X X X X X X X X X X X X X X X X X X LRO X X X X - TSO X X X X X X X X X X X X - promiscuous mode X X X X X X X X X X X X X X X X - allmulticast modeX X X X X X X X X X X X X X X X X - unicast MAC filter X X X X X X X X X X X X X X - multicast MAC filter X X X X X X X - RSS hash X X X X X X X X X X X X X X - RSS key update X X X X X X X X X X X - RSS reta update X X X X X X X X X X X - VMDq X X X X X - SR-IOV
[dpdk-dev] [PATCH v2] doc: update nic overview
Hi, Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, April 07, 2016 3:54 PM > To: Chen, Jing D > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] doc: update nic overview > > Hi Mark, > > I'm waiting for these small comments. > Please could you rebase your patch and fix it if needed? > Sorry, will do today. > 2016-04-06 10:33, Thomas Monjalon: > > 2016-04-01 16:55, Chen Jing D: > > > - stats per queue X > > > X > > > + stats per queue X > > > X > > > > I think you should fill "stats per queue" > > > > > BSD nic_uio X X X X X > > > > What is the issue with BSD? >
[dpdk-dev] [PATCH v2] doc: update nic overview
Thomas,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Saturday, April 02, 2016 5:40 AM
> To: Chen, Jing D
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] doc: update nic overview
>
> 2016-04-01 16:55, Chen Jing D:
> > Add feature support list for fm10k, fm10k-vec, fm10kvf and
> > fm10kvf-vec.
>
> Please help me to understand what is fm10kvf.
> I see only one fm10k driver:
> % git grep 'struct eth_driver' drivers/net/fm10k/
> drivers/net/fm10k/fm10k_ethdev.c:static struct eth_driver rte_pmd_fm10k
> = {
You can refer to below definition:
static const struct rte_pci_id pci_id_fm10k_map[] = {
#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
#include "rte_pci_dev_ids.h"
{ .vendor_id = 0, /* sentinel */ },
};
As you can see that fm10k driver will manage 2 different types of devices, PF
and VF.
We can say that there are 2 drivers under fm10k directory. The aspects that not
applicable
to PF/VF will use condition check to control execution path. This makes driver
can work with
PF and VF devices and reduce redundant code.
[dpdk-dev] [PATCH v2] doc: update nic overview
From: "Chen Jing D(Mark)" Add feature support list for fm10k, fm10k-vec, fm10kvf and fm10kvf-vec. Signed-off-by: Chen Jing D(Mark) --- v2: - fix a typo doc/guides/nics/overview.rst | 86 +- 1 files changed, 43 insertions(+), 43 deletions(-) diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst index 542479a..b5d1c2c 100644 --- a/doc/guides/nics/overview.rst +++ b/doc/guides/nics/overview.rst @@ -74,39 +74,39 @@ Most of these differences are summarized below. .. table:: Features availability in networking drivers - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - Feature a b b b c e e e i i i i i i i i i i f f m m m n n p r s v v v v x -f n n o x 1 n n 4 4 4 4 g g x x x x m m l l p f u c i z h i i m e -p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 x x i p l a n e o r r x n -a 2 2 d b 0 c e e e e v b b b b 0 0 4 5 p l p g d s t t n v -c x x i e 0 . v v f e e e e k k e a t i i e i -k v n . f f . v v . t o o t r -e f g . . . f f . a . 3 t -t v v v v v 2 v - e e e e e e - c c c c c c - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - link status X X X X X - link status eventX X X - queue status event X - Rx interrupt X X X X - queue start/stop X X X X X X X + = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = + Feature a b b b c e e e i i i i i i i i i i f f f f m m m n n p r s v v v v x +f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f u c i z h i i m e +p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p l a n e o r r x n +a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p l p g d s t t n v +c x x i e 0 . v v f e e e e k k k k e a t i i e i +k v n . f f . v v . v v t o o t r +e f g . . . f f . f f a . 3 t +t v v v v v v 2 v + e e e e e e e + c c c c c c c + = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = + link status X X X X X + link status eventX X X + queue status event X + Rx interrupt X X X X X X X X + queue start/stop X X X X X X X X X X X MTU update X X - jumbo frame X X X X X X - scattered Rx X X X X X X X + jumbo frame X X X X X X X X X X + scattered Rx X X X X X X X X X X X LRO - TSO X X X X X X - promiscuous mode X X X X X X - allmulticast modeX X X X X X - unicast MAC filter X X X X - multicast MAC filter X X X X - RSS hash X X X X X X - RSS key update X X X X X - RSS reta update X X X X X - VMDq X X + TSO X X X X X X X X X X + promiscuous mode X X X X X X X X + allmulticast modeX X X X X X X X + unicast MAC filter X X X X X X + multicast MAC filter X X X X X X + RSS hash X X X X X X X X X X + RSS key update X X X X X X X X X + RSS r
[dpdk-dev] [PATCH] doc: update nic overview
From: "Chen Jing D(Mark)" Add feature support list for fm10k, fm10k-vec, fm10kvf and fm10kvf-vec. Signed-off-by: Chen Jing D(Mark) --- doc/guides/nics/overview.rst | 86 +- 1 files changed, 43 insertions(+), 43 deletions(-) diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst index 542479a..4f6ad9e 100644 --- a/doc/guides/nics/overview.rst +++ b/doc/guides/nics/overview.rst @@ -74,39 +74,39 @@ Most of these differences are summarized below. .. table:: Features availability in networking drivers - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - Feature a b b b c e e e i i i i i i i i i i f f m m m n n p r s v v v v x -f n n o x 1 n n 4 4 4 4 g g x x x x m m l l p f u c i z h i i m e -p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 x x i p l a n e o r r x n -a 2 2 d b 0 c e e e e v b b b b 0 0 4 5 p l p g d s t t n v -c x x i e 0 . v v f e e e e k k e a t i i e i -k v n . f f . v v . t o o t r -e f g . . . f f . a . 3 t -t v v v v v 2 v - e e e e e e - c c c c c c - = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - link status X X X X X - link status eventX X X - queue status event X - Rx interrupt X X X X - queue start/stop X X X X X X X + = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = + Feature a b b b c e e e i i i i i i i i i i f f f f m m m n n p r s v v v v x +f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f u c i z h i i m e +p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p l a n e o r r x n +a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p l p g d s t t n v +c x x i e 0 . v v f e e e e k k k k e a t i i e i +k v n . f f . v v . v . t o o t r +e f g . . . f f . f . a . 3 t +t v v v v v v 2 v + e e e e e e e + c c c c c c c + = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = + link status X X X X X + link status eventX X X + queue status event X + Rx interrupt X X X X X X X X + queue start/stop X X X X X X X X X X X MTU update X X - jumbo frame X X X X X X - scattered Rx X X X X X X X + jumbo frame X X X X X X X X X X + scattered Rx X X X X X X X X X X X LRO - TSO X X X X X X - promiscuous mode X X X X X X - allmulticast modeX X X X X X - unicast MAC filter X X X X - multicast MAC filter X X X X - RSS hash X X X X X X - RSS key update X X X X X - RSS reta update X X X X X - VMDq X X + TSO X X X X X X X X X X + promiscuous mode X X X X X X X X + allmulticast modeX X X X X X X X + unicast MAC filter X X X X X X + multicast MAC filter X X X X X X + RSS hash X X X X X X X X X X + RSS key update X X X X X X X X X + RSS reta update X
[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization
Thomas, We've agreed offline that the patch works without side effect. Please kindly apply if possible. > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, March 31, 2016 9:57 PM > To: dev at dpdk.org > Cc: Michael Frasca ; Chen, Jing D > > Subject: Re: [dpdk-dev] [PATCH] fm10k: conditionally disable RSS during > device initialization > > Please, anyone to confirm that the patch is valid and must be applied? > This discussion shows some doubts. > > > 2016-03-24 13:35, Michael Frasca: > > Jing, > > > > Thanks for your assistance. The experiment that you have built should > > allow you to observe the bug. In [5], I would expect that queue 0 > > receives roughly 1/4 of the packets that you sending, assuming the > > input packets have varied IP addresses. Can you measure what % of > > packets are actually being received in this single queue setup (after first > running a 4-queue setup)? > > > > When trying to running with only one RX queue, the fm10k retains the > > same RSS hash function and redirection table that was configured from > > a previous run. As a result, some packets are still being directed to > > other receive queues. I have confirmed this by polling the queue > > specific stats, which I retrieved via rte_eth_xstats_get(). > > > > Looking at fm10k_dev_rss_configure(), one should see that there is no > > modification of fm10k registers when nb_rx_queues == 1. As far as I > > can tell, this is the reason that only a certain partition of packets > > are being receive in a single queue setup (after first running a multi-queue > configuration). > > > > I am unable to access my development environment today, but if you > > need, I can later craft a patch to l3fwd that shows the measurement of > > packets received at each queue. > > > > Thanks, > > Mike > > > > > > > On Mar 24, 2016, at 2:40 AM, Chen, Jing D > > > wrote: > > > > > > Hi, Frasca, > > > > > > > > > > > >> -Original Message- > > >> From: Michael Frasca [mailto:michael.frasca at oracle.com > > >> <mailto:michael.frasca at oracle.com>] > > >> Sent: Wednesday, March 23, 2016 9:43 PM > > >> To: Chen, Jing D > > >> Cc: dev at dpdk.org <mailto:dev at dpdk.org> > > >> Subject: Re: [PATCH] fm10k: conditionally disable RSS during device > > >> initialization > > >> > > >> Hi Jing, > > >> > > >> I ran into this issue while trying to run experiments with > > >> different RSS configurations (no RSS being one cases). It is not > > >> clear to me that setting this register to zero is the best way to disable > RSS. > > >> > > >> After digging further, I have a theory that I'm having this issues > > >> because I've only attached my DPDK application to SR-IOV ports. In > > >> fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set > > >> for the DGLORT decoder. However, it appears that this is only > > >> invoked for physical functions. > > >> > > >> Could this be my problem? Is it required that I bind to the > > >> physical function if I want to properly manipulate RSS? > > >> > > >> Thanks, > > >> Mike > > >> > > > I don't know exactly what problem you ran into. I think we needn't > > > worry about those DGLORT setting when using VF device. > > > > > > I've followed steps to use SRIOV device with RSS enabled and > > > disabled, both are worked well from my side after applying your patch. > Below is my setup. > > > > > > 1. PF with Linux driver "fm10k-next_0.19.3". > > > 2. DPDK with latest code from master branch, apply your patch. > > > 3. Use 1 VF device created by kernel driver. > > > 4. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 -- > config="(0,0,2),(0,1,2),(0,2,3),(0,3,3)"" > > >with RSS enabled. After sending packets, I can see all 4 queues > > > received > packets. > > > 5. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 -- > config="(0,0,2)"" > > >with RSS disabled. After sending packets, I can see queue 0 received > packets. > > > > > > Can you explain what actual problem is? > > > We can talk offline. > > >
[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization
Hi, Frasca, > -Original Message- > From: Michael Frasca [mailto:michael.frasca at oracle.com] > Sent: Wednesday, March 23, 2016 9:43 PM > To: Chen, Jing D > Cc: dev at dpdk.org > Subject: Re: [PATCH] fm10k: conditionally disable RSS during device > initialization > > Hi Jing, > > I ran into this issue while trying to run experiments with different RSS > configurations (no RSS being one cases). It is not clear to me that setting > this > register to zero is the best way to disable RSS. > > After digging further, I have a theory that I'm having this issues because > I've > only attached my DPDK application to SR-IOV ports. In > fm10k_dev_dglort_map_configure(), I see that 'RSS Length' is set for the > DGLORT > decoder. However, it appears that this is only invoked for physical functions. > > Could this be my problem? Is it required that I bind to the physical function > if I want to properly manipulate RSS? > > Thanks, > Mike > I don't know exactly what problem you ran into. I think we needn't worry about those DGLORT setting when using VF device. I've followed steps to use SRIOV device with RSS enabled and disabled, both are worked well from my side after applying your patch. Below is my setup. 1. PF with Linux driver "fm10k-next_0.19.3". 2. DPDK with latest code from master branch, apply your patch. 3. Use 1 VF device created by kernel driver. 4. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 --config="(0,0,2),(0,1,2),(0,2,3),(0,3,3)"" with RSS enabled. After sending packets, I can see all 4 queues received packets. 5. use l3fwd with " ./examples/l3fwd/build/l3fwd -c fc -n 4 -- -p 0x1 --config="(0,0,2)"" with RSS disabled. After sending packets, I can see queue 0 received packets. Can you explain what actual problem is? We can talk offline.
[dpdk-dev] [PATCH] fm10k: conditionally disable RSS during device initialization
Hi,
> -Original Message-
> From: Michael Frasca [mailto:michael.frasca at oracle.com]
> Sent: Wednesday, March 23, 2016 12:58 AM
> To: Chen, Jing D
> Cc: dev at dpdk.org; Michael Frasca
> Subject: [PATCH] fm10k: conditionally disable RSS during device initialization
>
> If the provided configuration does not call for RSS, then RSS is
> explicitly disabled. Without this change, the device continues to
> operate under the previous RSS configuration.
>
> Fixes: 57033cdf8fdc ("fm10k: add PF RSS")
>
> Signed-off-by: Michael Frasca
Acked-by : Jing Chen
[dpdk-dev] [PATCH v11 5/8] ethdev: add speed capabilities
Hi, Best Regards, Mark > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, March 18, 2016 2:09 AM > To: marcdevel at gmail.com; Richardson, Bruce; Doherty, Declan; Ananyev, > Konstantin; Lu, Wenzhuo; Zhang, Helin; Chen, Jing D; harish.patil at > qlogic.com; > rahul.lakkireddy at chelsio.com; johndale at cisco.com; vido at cesnet.cz; > adrien.mazarguil at 6wind.com; alejandro.lucero at netronome.com > Cc: dev at dpdk.org > Subject: [PATCH v11 5/8] ethdev: add speed capabilities > > From: Marc Sune > > The speed capabilities of a device can be retrieved with > rte_eth_dev_info_get(). > > The new field speed_capa is initialized in the drivers without > taking care of device characteristics in this patch. > When the capabilities of a driver are accurate, the table in > overview.rst must be filled. > > Signed-off-by: Marc Sune > --- > doc/guides/nics/overview.rst | 1 + > doc/guides/rel_notes/release_16_04.rst | 8 > drivers/net/bnx2x/bnx2x_ethdev.c | 1 + > drivers/net/cxgbe/cxgbe_ethdev.c | 1 + > drivers/net/e1000/em_ethdev.c | 4 > drivers/net/e1000/igb_ethdev.c | 4 > drivers/net/fm10k/fm10k_ethdev.c | 4 > drivers/net/i40e/i40e_ethdev.c | 8 > drivers/net/ixgbe/ixgbe_ethdev.c | 8 > drivers/net/mlx4/mlx4.c| 2 ++ > drivers/net/mlx5/mlx5_ethdev.c | 3 +++ > drivers/net/nfp/nfp_net.c | 2 ++ > lib/librte_ether/rte_ethdev.h | 21 + > 13 files changed, 67 insertions(+) > > > static void > diff --git a/drivers/net/fm10k/fm10k_ethdev.c > b/drivers/net/fm10k/fm10k_ethdev.c > index edc8c11..2a1c222 100644 > --- a/drivers/net/fm10k/fm10k_ethdev.c > +++ b/drivers/net/fm10k/fm10k_ethdev.c > @@ -1410,6 +1410,10 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev, > .nb_min = FM10K_MIN_TX_DESC, > .nb_align = FM10K_MULT_TX_DESC, > }; > + > + dev_info->speed_capa = ETH_LINK_SPEED_1G | > ETH_LINK_SPEED_2_5G | > + ETH_LINK_SPEED_10G | ETH_LINK_SPEED_25G | > + ETH_LINK_SPEED_40G; > } > Fm10k has 100G capability, we'd better to add ETH_LINK_SPEED_100G here.
[dpdk-dev] [PATCH v3 00/18] fm10k: update shared code
Hi, Xiao > -Original Message- > From: Wang, Xiao W > Sent: Tuesday, March 8, 2016 8:15 AM > To: Richardson, Bruce ; Chen, Jing D > > Cc: Chen, Jing D ; dev at dpdk.org; He, Shaopeng > > Subject: RE: [PATCH v3 00/18] fm10k: update shared code > > > > > -Original Message- > > From: Richardson, Bruce > > Sent: Tuesday, March 8, 2016 9:24 PM > > To: Wang, Xiao W ; Chen, Jing D > > > > Cc: Chen, Jing D ; dev at dpdk.org; He, Shaopeng > > > > Subject: Re: [PATCH v3 00/18] fm10k: update shared code > > > > On Fri, Feb 19, 2016 at 07:06:47PM +0800, Wang Xiao W wrote: > > > v3: > > > * Fixed checkpatch.pl warning about long commit message. > > > * Fixed the issue of compile failure about part of patches applied. > > > * Split the misc-small-fixes patch into several patches. > > > > > > v2: > > > * Put the two extra fix patches ahead of the base code patches. > > > > > > This patch set has passed regression test. > > > > > > Wang Xiao W (18): > > > fm10k: use default mailbox message handler for PF > > > fm10k/base: correct typecast in fm10k_update_xc_addr_pf > > > fm10k/base: cleanup namespace pollution > > > fm10k/base: use bitshift for itr_scale > > > fm10k/base: reset max_queues on init_hw_vf failure > > > fm10k/base: document ITR scale workaround in VF TDLEN register > > > fm10k/base: cleanup lines over 80 characters > > > fm10k/base: cleanup useless else > > > fm10k/base: use BIT macro instead of open-coded bit-shifting of 1 > > > fm10k/base: do not use CamelCase > > > fm10k/base: use memcpy for mac addr copy > > > fm10k/base: allow removal of is_slot_appropriate function > > > fm10k/base: consistently use VLAN ID when referencing vid variables > > > fm10k/base: imporve comment per upstream review changes > > > fm10k/base: fix TLV structures alignment > > > fm10k/base: move constants to the right of binary operators > > > fm10k/base: minor cleanups > > > fm10k/base: remove unused struct element > > > > > > drivers/net/fm10k/base/fm10k_api.c | 2 + > > > drivers/net/fm10k/base/fm10k_api.h | 2 + > > > drivers/net/fm10k/base/fm10k_mbx.c | 63 +++- > > > drivers/net/fm10k/base/fm10k_mbx.h | 11 +-- > > > drivers/net/fm10k/base/fm10k_osdep.h | 32 ++ > > > drivers/net/fm10k/base/fm10k_pf.c| 88 + > > > drivers/net/fm10k/base/fm10k_pf.h| 18 ++-- > > > drivers/net/fm10k/base/fm10k_tlv.c | 40 > > > drivers/net/fm10k/base/fm10k_tlv.h | 9 +- > > > drivers/net/fm10k/base/fm10k_type.h | 182 +++- > --- > > > drivers/net/fm10k/base/fm10k_vf.c| 32 -- > > > drivers/net/fm10k/fm10k_ethdev.c | 41 +++- > > > 12 files changed, 222 insertions(+), 298 deletions(-) > > > > > > -- > > > 1.9.3 > > > > > Hi Mark, > > > > Can we get fm10k maintainer review and/or ack on this patchset please. > > > > Thanks, > > /Bruce > > Hi Bruce, > > Mark has reviewed and acked the patch set in v2, and I put the "Acked-by " > in the v3 01/18 patch. > It's the same for my FTAG patch. > It's better to add acked-by in both patch set and cover letter, this may be more helpful for maintainers. > Best Regards, > Xiao
[dpdk-dev] [PATCH v4 05/12] pmd/fm10k: add dev_ptype_info_get implementation
Hi,
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jianfeng Tan
Sent: Thursday, February 25, 2016 6:09 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v4 05/12] pmd/fm10k: add dev_ptype_info_get
implementation
Signed-off-by: Jianfeng Tan
---
drivers/net/fm10k/fm10k_ethdev.c | 50 ++
drivers/net/fm10k/fm10k_rxtx.c | 3 +++
drivers/net/fm10k/fm10k_rxtx_vec.c | 3 +++
3 files changed, 56 insertions(+)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 421266b..429cbdd 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1335,6 +1335,55 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
};
}
+#ifdef RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE
+static const uint32_t *
+fm10k_dev_ptype_info_get(struct rte_eth_dev *dev) {
+ if (dev->rx_pkt_burst == fm10k_recv_pkts ||
+ dev->rx_pkt_burst == fm10k_recv_scattered_pkts) {
+ static uint32_t ptypes[] = {
+ /* refers to rx_desc_to_ol_flags() */
+ RTE_PTYPE_L2_ETHER,
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ return ptypes;
+ } else if (dev->rx_pkt_burst == fm10k_recv_pkts_vec ||
+ dev->rx_pkt_burst == fm10k_recv_scattered_pkts_vec) {
+ static uint32_t ptypes_vec[] = {
+ /* refers to fm10k_desc_to_pktype_v() */
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_TUNNEL_GENEVE,
+ RTE_PTYPE_TUNNEL_NVGRE,
+ RTE_PTYPE_TUNNEL_VXLAN,
+ RTE_PTYPE_TUNNEL_GRE,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ return ptypes_vec;
+ }
+
+ return NULL;
+}
May I know when " fm10k_dev_ptype_info_get " will be called? In fm10k, the
actual
Rx/tx func will be decided after port is started.
[dpdk-dev] [PATCH v3] doc: add Vector FM10K introductions
From: "Chen Jing D(Mark)" Add introductions on how to enable Vector FM10K Rx/Tx functions, the preconditions and assumptions on Rx/Tx configuration parameters. The new content also lists the limitations of vector, so app/customer can do better to select best Rx/Tx functions. Signed-off-by: Chen Jing D(Mark) --- v3: - rebase to dpdk-next-16.04 - Minor change to reword a few sentences. v2: - rebase to latest repo - Reword a few sentences that not follow coding style. doc/guides/nics/fm10k.rst | 98 + 1 files changed, 98 insertions(+), 0 deletions(-) diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst index 4206b7f..b97f611 100644 --- a/doc/guides/nics/fm10k.rst +++ b/doc/guides/nics/fm10k.rst @@ -35,6 +35,104 @@ The FM10K poll mode driver library provides support for the Intel FM1 (FM10K) family of 40GbE/100GbE adapters. +Vector PMD for FM10K + + +Vector PMD (vPMD) uses Intel? SIMD instructions to optimize packet I/O. +It improves load/store bandwidth efficiency of L1 data cache by using a wider +SSE/AVX ''register (1)''. +The wider register gives space to hold multiple packet buffers so as to save +on the number of instructions when bulk processing packets. + +There is no change to the PMD API. The RX/TX handlers are the only two entries for +vPMD packet I/O. They are transparently registered at runtime RX/TX execution +if all required conditions are met. + +1. To date, only an SSE version of FM10K vPMD is available. +To ensure that vPMD is in the binary code, set +``CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y`` in the configure file. + +Some constraints apply as pre-conditions for specific optimizations on bulk +packet transfers. The following sections explain RX and TX constraints in the +vPMD. + + +RX Constraints +~~ + + +Prerequisites and Pre-conditions + + +For Vector RX it is assumed that the number of descriptor rings will be a power +of 2. With this pre-condition, the ring pointer can easily scroll back to the +head after hitting the tail without a conditional check. In addition Vector RX +can use this assumption to do a bit mask using ``ring_size - 1``. + + +Features not Supported by Vector RX PMD +^^^ + +Some features are not supported when trying to increase the throughput in +vPMD. They are: + +* IEEE1588 + +* Flow director + +* Header split + +* RX checksum offload + +Other features are supported using optional MACRO configuration. They include: + +* HW VLAN strip + +* L3/L4 packet type + +To enable via ``RX_OLFLAGS`` use ``RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y``. + +To guarantee the constraint, the following configuration flags in ``dev_conf.rxmode`` +will be checked: + +* ``hw_vlan_extend`` + +* ``hw_ip_checksum`` + +* ``header_split`` + +* ``fdir_conf->mode`` + + +RX Burst Size +^ + +As vPMD is focused on high throughput, it processes 4 packets at a time. So it assumes +that the RX burst should be greater than 4 packets per burst. It returns zero if using +``nb_pkt`` < 4 in the receive handler. If ``nb_pkt`` is not a multiple of 4, a +floor alignment will be applied. + + +TX Constraint +~ + +Features not Supported by TX Vector PMD +^^^ + +TX vPMD only works when ``txq_flags`` is set to ``FM10K_SIMPLE_TX_FLAG``. +This means that it does not support TX multi-segment, VLAN offload or TX csum +offload. The following MACROs are used for these three features: + +* ``ETH_TXQ_FLAGS_NOMULTSEGS`` + +* ``ETH_TXQ_FLAGS_NOVLANOFFL`` + +* ``ETH_TXQ_FLAGS_NOXSUMSCTP`` + +* ``ETH_TXQ_FLAGS_NOXSUMUDP`` + +* ``ETH_TXQ_FLAGS_NOXSUMTCP`` + Limitations --- -- 1.7.7.6
[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
Hi, Bruce, > -Original Message- > From: Richardson, Bruce > Sent: Thursday, February 25, 2016 9:35 PM > To: Chen, Jing D > Cc: Thomas Monjalon ; Wang, Xiao W > ; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based > forwarding > > On Thu, Feb 25, 2016 at 10:04:02AM +, Chen, Jing D wrote: > > Hi, Bruce, Thomas, > > > > Best Regards, > > Mark > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas > Monjalon > > > Sent: Thursday, February 25, 2016 12:38 AM > > > To: Richardson, Bruce; Wang, Xiao W > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based > > > forwarding > > > > > > 2016-02-24 15:42, Bruce Richardson: > > > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote: > > > > > This patch enables reading sglort info into mbuf for RX and > > > > > inserting an FTAG at the beginning of the packet for TX. The > > > > > vlan_tci_outer field selected from rte_mbuf structure for sglort is > > > > > not > used in fm10k now. > > > > > In FTAG based forwarding mode, the switch will forward packets > > > according > > > > > to glort info in FTAG rather than mac and vlan table. > > > > > > > > > > To activate this feature, user needs to turn > > > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD`` > > > > > to y in common_linuxapp or common_bsdapp. Currently this feature > > > > > is > > > supported > > > > > only on PF, because FM10K_PFVTCTL register is read-only for VF. > > > > > > > > > > Signed-off-by: Wang Xiao W > > > > > > > > Any comments on this patch? > > > > > > > > My thoughts: is there a way in which this could be done without > > > > adding in a > > > new > > > > build time config option? > > > > > > Bruce, it's simpler to explain that build time options are forbidden > > > to enable such options. > > > Or the terrific kid's approach: one day, the Big Build-Option Eater > > > will come and will eat every undecided features! ;) > > > > This feature is trying to use FTAG (a unique tech in fm10k) instead of > > mac/vlan to forward packets. App need a way to tell PMD driver that > > which forwarding style it would like to use. > > Why not just specify this in the port configuration at setup time? > Please educate me. I think the port configuration flags are also common to all PMD Drivers. Is it possible to add a flag like "RTE_USE_FTAG" and pass to PMD driver? > > So, the best option is to let packets carry a flag in mbuf to tell drive in > > fast > path. > > You can see that this is unique to fm10k and we thought community > > won't like to see this flag introduced into mbuf. If you do agree, we can > introduce a new flag. > > Why does it need to be specified per-mbuf? The existing config flag added is > global, so a per-mbuf flag shouldn't be needed to get equivalent behaviour. > > > So, we step backwards and assume customer will use static > > configurations to enable this feature. After it is enabled, we'll assume app > will use FTAG for all packets. > > Yes, but instead of compile time option, why not port config-time option > instead? > > /Bruce
[dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based forwarding
Hi, Bruce, Thomas, Best Regards, Mark > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Thursday, February 25, 2016 12:38 AM > To: Richardson, Bruce; Wang, Xiao W > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 1/3] fm10k: enable FTAG based > forwarding > > 2016-02-24 15:42, Bruce Richardson: > > On Thu, Feb 04, 2016 at 11:38:47AM +0800, Wang Xiao W wrote: > > > This patch enables reading sglort info into mbuf for RX and inserting > > > an FTAG at the beginning of the packet for TX. The vlan_tci_outer field > > > selected from rte_mbuf structure for sglort is not used in fm10k now. > > > In FTAG based forwarding mode, the switch will forward packets > according > > > to glort info in FTAG rather than mac and vlan table. > > > > > > To activate this feature, user needs to turn > ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD`` > > > to y in common_linuxapp or common_bsdapp. Currently this feature is > supported > > > only on PF, because FM10K_PFVTCTL register is read-only for VF. > > > > > > Signed-off-by: Wang Xiao W > > > > Any comments on this patch? > > > > My thoughts: is there a way in which this could be done without adding in a > new > > build time config option? > > Bruce, it's simpler to explain that build time options are forbidden to > enable such options. > Or the terrific kid's approach: one day, the Big Build-Option Eater will come > and will eat every undecided features! ;) This feature is trying to use FTAG (a unique tech in fm10k) instead of mac/vlan to forward packets. App need a way to tell PMD driver that which forwarding style it would like to use. So, the best option is to let packets carry a flag in mbuf to tell drive in fast path. You can see that this is unique to fm10k and we thought community won't like to see this flag introduced into mbuf. If you do agree, we can introduce a new flag. So, we step backwards and assume customer will use static configurations to enable this feature. After it is enabled, we'll assume app will use FTAG for all packets.
[dpdk-dev] [PATCH v2] doc: add Vector FM10K introductions
Hi, John, Best Regards, Mark > -Original Message- > From: Mcnamara, John > Sent: Monday, February 22, 2016 9:47 PM > To: Chen, Jing D; dev at dpdk.org > Subject: RE: [PATCH v2] doc: add Vector FM10K introductions > > > -Original Message----- > > From: Chen, Jing D > > Sent: Saturday, February 6, 2016 6:48 AM > > To: dev at dpdk.org > > Cc: Mcnamara, John ; Chen, Jing D > > > > Subject: [PATCH v2] doc: add Vector FM10K introductions > > > > From: "Chen Jing D(Mark)" > > > > Add introductions on how to enable Vector FM10K Rx/Tx functions, the > > preconditions and assumptions on Rx/Tx configuration parameters. > > Hi Mark, > > Thanks for the update. A few minor comments below. > > > > > +Vector PMD (vPMD) uses Intel? SIMD instructions to optimize packet I/O. > > +It improves load/store bandwidth efficiency of L1 data cache by using a > > +wider SSE/AVX register 1 (1). > > This should probably be "register (1)" > > > > +The wider register gives space to hold multiple packet buffers so as to > > +save instruction number when processing bulk of packets. > > Maybe a little clearer as: > > The wider register gives space to hold multiple packet buffers so as to save > on the number of instructions when bulk processing packets. > > > > + > > +There is no change to PMD API. The RX/TX handler are the only two > > +entries for vPMD packet I/O. They are transparently registered at > > +runtime RX/TX execution if all condition checks pass. > > s/if all condition checks pass./if all conditions are met./ > > > > +As vPMD is focused on high throughput, it 4 packets at a time. So it > > s/it 4 packets at a time/it processes 4 packets at a time/ > > John Many thanks for the comments. I'll change and send a new version soon.
[dpdk-dev] [PATCH] fm10k: optimize legacy TX func
Hi, Bruce, > -Original Message- > From: Richardson, Bruce > Sent: Tuesday, February 16, 2016 11:28 PM > To: Chen, Jing D > Cc: Qiu, Michael; Ananyev, Konstantin; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] fm10k: optimize legacy TX func > > On Thu, Jan 28, 2016 at 05:45:59PM +0800, Chen Jing D(Mark) wrote: > > From: "Chen Jing D(Mark)" > > > > When legacy TX func tries to free a bunch of mbufs, it will free them > > one by one. This change will scan the free list and merge the requests > > in case they belongs to same pool, then free once, which will reduce > > cycles on freeing mbufs. > > > > Signed-off-by: Chen Jing D(Mark) > > --- > > doc/guides/rel_notes/release_2_3.rst |2 + > > drivers/net/fm10k/fm10k_rxtx.c | 59 > - > > 2 files changed, 52 insertions(+), 9 deletions(-) > > > > diff --git a/doc/guides/rel_notes/release_2_3.rst > > b/doc/guides/rel_notes/release_2_3.rst > > index 99de186..20ce78d 100644 > > --- a/doc/guides/rel_notes/release_2_3.rst > > +++ b/doc/guides/rel_notes/release_2_3.rst > > @@ -3,7 +3,9 @@ DPDK Release 2.3 > > > > New Features > > > > +* **Optimize fm10k Tx func.** > > > > + * Free multiple mbufs at a time to reduce freeing mbuf cycles. > > > > Is this really a significant enough change to warrant being called out in the > release notes? > Personally, I don't think so, so if you are ok with it, I'll just apply this > patch > without the RN update. > > /Bruce This change will have some performance gain with legacy TX func. That's why I'd like to add a line in release notes. If you thinks it's not necessary, please kindly remove it.
[dpdk-dev] [PATCH v3] fm10k: fix switch manager high CPU usage
Hi,
Best Regards,
Mark
> -Original Message-
> From: He, Shaopeng
> Sent: Friday, February 05, 2016 10:46 AM
> To: dev at dpdk.org
> Cc: Chen, Jing D; Wang, Xiao W; He, Shaopeng
> Subject: [PATCH v3] fm10k: fix switch manager high CPU usage
>
> fm10k switch core uses source MAC + VID + SGLORT to do
> look up in MAC table. If no match, an exception interrupt
> will be sent to the switch manager. Too much of this kind
> of exception interrupts cause switch manager side high CPU
> usage.
> To reproduce this issue, one DPDK testpmd runs on a server
> with one fm10k NIC, mac forwards test traffic from one of
> fm10k ports to another port. The CPU usage for the switch
> manager will go up to about 20% for test traffic rate at
> 10G bps, comparing to near 0% for no test traffic.
> This patch fixes this issue. A default SGLORT is assigned
> to each TX queue. This default value works for non-VMDq mode
> and current VMDq example. For advanced VMDq usage, e.g.
> different source MAC address for different TX queue, FTAG
> forwarding function could be used to change this default
> SGLORT value.
>
> Fixes: 9ae6068c ("fm10k: add dev start/stop")
>
> Signed-off-by: Shaopeng He
Acked-by : Jing Chen
[dpdk-dev] [PATCH v2 00/16] fm10k: update shared code
Hi, Best Regards, Mark > -Original Message- > From: Wang, Xiao W > Sent: Wednesday, January 27, 2016 11:51 AM > To: Chen, Jing D > Cc: dev at dpdk.org; Richardson, Bruce; He, Shaopeng; Wang, Xiao W > Subject: [PATCH v2 00/16] fm10k: update shared code > > v2: > * Put the two extra fix patches ahead of the base code patches. > > Wang Xiao W (16): > fm10k: use default mailbox message handler for pf > fm10k/base: add macro definitions that are needed > fm10k/base: cleanup namespace pollution and correct typecast > fm10k/base: use bitshift for itr_scale > fm10k/base: reset max_queues on init_hw_vf failure > fm10k/base: document ITR scale workaround in VF TDLEN register > fm10k/base: fix checkpatch warning > fm10k/base: use BIT macro instead of open-coded bit-shifting of 1 > fm10k/base: do not use CamelCase > fm10k/base: use memcpy for mac addr copy > fm10k/base: allow removal of is_slot_appropriate function > fm10k/base: consistently use VLAN ID when referencing vid variables > fm10k/base: fix comment per upstream review changes > fm10k/base: TLV structures must be 4byte aligned, not 1byte aligned > fm10k/base: move constants to the right of binary operators > fm10k/base: minor cleanups > > drivers/net/fm10k/base/fm10k_api.c | 2 + > drivers/net/fm10k/base/fm10k_api.h | 2 + > drivers/net/fm10k/base/fm10k_mbx.c | 63 +++- > drivers/net/fm10k/base/fm10k_mbx.h | 11 +-- > drivers/net/fm10k/base/fm10k_osdep.h | 30 ++ > drivers/net/fm10k/base/fm10k_pf.c| 88 + > drivers/net/fm10k/base/fm10k_pf.h| 18 ++-- > drivers/net/fm10k/base/fm10k_tlv.c | 40 > drivers/net/fm10k/base/fm10k_tlv.h | 9 +- > drivers/net/fm10k/base/fm10k_type.h | 182 +++-- > -- > drivers/net/fm10k/base/fm10k_vf.c| 32 -- > drivers/net/fm10k/fm10k_ethdev.c | 41 +++- > 12 files changed, 220 insertions(+), 298 deletions(-) > > -- > 1.9.3 Acked-by : Jing Chen
[dpdk-dev] [PATCH v8 2/4] ethdev: Fill speed capability bitmaps in the PMDs
Hi, Marc, Best Regards, Mark > -Original Message- > From: N?lio Laranjeiro [mailto:nelio.laranjeiro at 6wind.com] > Sent: Monday, February 15, 2016 4:43 PM > To: Marc Sune > Cc: dev at dpdk.org; Lu, Wenzhuo; Zhang, Helin; Harish Patil; Chen, Jing D > Subject: Re: [dpdk-dev] [PATCH v8 2/4] ethdev: Fill speed capability bitmaps > in the PMDs > > On Sun, Feb 14, 2016 at 11:17:37PM +0100, Marc Sune wrote: > > Added speed capabilities to all pmds supporting physical NICs: > > > > * e1000 > > * ixgbe > > * i40 > > * bnx2x > > * cxgbe > > * mlx4 > > * mlx5 > > * nfp > > * fm10k > >[...] > > diff --git a/drivers/net/mlx5/mlx5_ethdev.c > b/drivers/net/mlx5/mlx5_ethdev.c > > index 1159fa3..99dac09 100644 > > --- a/drivers/net/mlx5/mlx5_ethdev.c > > +++ b/drivers/net/mlx5/mlx5_ethdev.c > > @@ -523,6 +523,11 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, > struct rte_eth_dev_info *info) > > * size if it is not fixed. > > * The API should be updated to solve this problem. */ > > info->reta_size = priv->ind_table_max_size; > > + > > + info->speed_capa = ETH_SPEED_CAP_1G | ETH_SPEED_CAP_10G | > > + ETH_SPEED_CAP_10G | > ETH_SPEED_CAP_40G | > > + ETH_SPEED_CAP_56G; > > + > > priv_unlock(priv); > > } > > Hi Marc, > > I have a question about this information, is it a list of the > capabilities of the family or the capability of the NIC? > Because with ConnectX4 family we have a range of NICs which does not > support all this kind of speeds. > > The speeds above are not completed the range is 1/10/25/40/50/100G. > Fm10k also includes several cards and different ones are designed to have different speed. A better solution for fm10k is to acquire NIC type (like, BR card for 100G/40G, Atwood for 25/10G, etc) Then, return proper speed. > -- > N?lio Laranjeiro > 6WIND
[dpdk-dev] [PATCH v2] fm10k: handle err flags in vector RX func
From: "Chen Jing D(Mark)"
Using SSE instructions to parse error flags in HW Rx descriptor,
then set corresponding bits of mbuf.
Signed-off-by: Chen Jing D(Mark)
---
v2:
- rebase to latest repo
- fix a typo in the processing of HBO and IXE error flags
doc/guides/rel_notes/release_2_3.rst |4 +++
drivers/net/fm10k/fm10k_rxtx_vec.c | 42 +-
2 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst
b/doc/guides/rel_notes/release_2_3.rst
index 7945694..6715351 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -39,6 +39,10 @@ This section should contain new features added in this
release. Sample format:
Enabled virtio 1.0 support for virtio pmd driver.
+* **Handle error flags in fm10k vector RX func**
+
+ * Parse err flags in Rx desc and set error bits in mbuf with vector
instructions.
+
Resolved Issues
---
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 2a57eef..9f178db 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -61,11 +61,17 @@ fm10k_reset_tx_queue(struct fm10k_tx_queue *txq);
#define L3TYPE_SHIFT (4)
/* L4 type shift */
#define L4TYPE_SHIFT (7)
+/* HBO flag shift */
+#define HBOFLAG_SHIFT (10)
+/* RXE flag shift */
+#define RXEFLAG_SHIFT (13)
+/* IPE/L4E flag shift */
+#define L3L4EFLAG_SHIFT (14)
static inline void
fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf **rx_pkts)
{
- __m128i ptype0, ptype1, vtag0, vtag1;
+ __m128i ptype0, ptype1, vtag0, vtag1, eflag0, eflag1, cksumflag;
union {
uint16_t e[4];
uint64_t dword;
@@ -81,12 +87,29 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
**rx_pkts)
0x, 0x, 0x, 0x,
0x000F, 0x000F, 0x000F, 0x000F);
+ /* mask for HBO and RXE flag flags */
+ const __m128i rxe_msk = _mm_set_epi16(
+ 0x, 0x, 0x, 0x,
+ 0x0001, 0x0001, 0x0001, 0x0001);
+
+ const __m128i l3l4cksum_flag = _mm_set_epi8(0, 0, 0, 0,
+ 0, 0, 0, 0,
+ 0, 0, 0, 0,
+ PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD,
+ PKT_RX_IP_CKSUM_BAD, PKT_RX_L4_CKSUM_BAD, 0);
+
+ const __m128i rxe_flag = _mm_set_epi8(0, 0, 0, 0,
+ 0, 0, 0, 0,
+ 0, 0, 0, 0,
+ 0, 0, PKT_RX_RECIP_ERR, 0);
+
/* map rss type to rss hash flag */
const __m128i rss_flags = _mm_set_epi8(0, 0, 0, 0,
0, 0, 0, PKT_RX_RSS_HASH,
PKT_RX_RSS_HASH, 0, PKT_RX_RSS_HASH, 0,
PKT_RX_RSS_HASH, PKT_RX_RSS_HASH, PKT_RX_RSS_HASH, 0);
+ /* Calculate RSS_hash and Vlan fields */
ptype0 = _mm_unpacklo_epi16(descs[0], descs[1]);
ptype1 = _mm_unpacklo_epi16(descs[2], descs[3]);
vtag0 = _mm_unpackhi_epi16(descs[0], descs[1]);
@@ -97,10 +120,27 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
**rx_pkts)
ptype0 = _mm_shuffle_epi8(rss_flags, ptype0);
vtag1 = _mm_unpacklo_epi32(vtag0, vtag1);
+ eflag0 = vtag1;
+ cksumflag = vtag1;
vtag1 = _mm_srli_epi16(vtag1, VP_SHIFT);
vtag1 = _mm_and_si128(vtag1, pkttype_msk);
vtag1 = _mm_or_si128(ptype0, vtag1);
+
+ /* Process err flags, simply set RECIP_ERR bit if HBO/IXE is set */
+ eflag1 = _mm_srli_epi16(eflag0, RXEFLAG_SHIFT);
+ eflag0 = _mm_srli_epi16(eflag0, HBOFLAG_SHIFT);
+ eflag0 = _mm_or_si128(eflag0, eflag1);
+ eflag0 = _mm_and_si128(eflag0, rxe_msk);
+ eflag0 = _mm_shuffle_epi8(rxe_flag, eflag0);
+
+ vtag1 = _mm_or_si128(eflag0, vtag1);
+
+ /* Process L4/L3 checksum error flags */
+ cksumflag = _mm_srli_epi16(cksumflag, L3L4EFLAG_SHIFT);
+ cksumflag = _mm_shuffle_epi8(l3l4cksum_flag, cksumflag);
+ vtag1 = _mm_or_si128(cksumflag, vtag1);
+
vol.dword = _mm_cvtsi128_si64(vtag1);
rx_pkts[0]->ol_flags = vol.e[0];
--
1.7.7.6
[dpdk-dev] [PATCH v2] doc: add Vector FM10K introductions
From: "Chen Jing D(Mark)" Add introductions on how to enable Vector FM10K Rx/Tx functions, the preconditions and assumptions on Rx/Tx configuration parameters. The new content also lists the limitations of vector, so app/customer can do better to select best Rx/Tx functions. Signed-off-by: Chen Jing D(Mark) --- v2: - rebase to latest repo - Reword a few sentences that not follow coding style. doc/guides/nics/fm10k.rst | 98 + 1 files changed, 98 insertions(+), 0 deletions(-) diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst index 4206b7f..a502ffd 100644 --- a/doc/guides/nics/fm10k.rst +++ b/doc/guides/nics/fm10k.rst @@ -35,6 +35,104 @@ The FM10K poll mode driver library provides support for the Intel FM1 (FM10K) family of 40GbE/100GbE adapters. +Vector PMD for FM10K + + +Vector PMD (vPMD) uses Intel? SIMD instructions to optimize packet I/O. +It improves load/store bandwidth efficiency of L1 data cache by using a wider +SSE/AVX register 1 (1). +The wider register gives space to hold multiple packet buffers so as to save +instruction number when processing bulk of packets. + +There is no change to PMD API. The RX/TX handler are the only two entries for +vPMD packet I/O. They are transparently registered at runtime RX/TX execution +if all condition checks pass. + +1. To date, only an SSE version of FM10K vPMD is available. +To ensure that vPMD is in the binary code, ensure that the option +CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y is in the configure file. + +Some constraints apply as pre-conditions for specific optimizations on bulk +packet transfers. The following sections explain RX and TX constraints in the +vPMD. + + +RX Constraints +~~ + + +Prerequisites and Pre-conditions + + +For Vector RX it is assumed that the number of descriptor ring will be power +of 2. With this pre-condition, the ring pointer can easily scroll back to the +head after hitting the tail without conditional check. In addition Vector RX +can use this assumption to do a bit mask using ``ring_size - 1``. + + +Features not Supported by Vector RX PMD +^^^ + +Some features are not supported when trying to increase the throughput in +vPMD. They are: + +* IEEE1588 + +* Flow director + +* Header split + +* RX checksum offload + +Other features are supported using optional MACRO configuration. They include: + +* HW VLAN strip + +* L3/L4 packet type + +To enabled by RX_OLFLAGS use ``RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y``. + +To guarantee the constraint, the configuration flags in ``dev_conf.rxmode`` +will be checked: + +* ``hw_vlan_extend`` + +* ``hw_ip_checksum`` + +* ``header_split`` + +* ``fdir_conf->mode`` + + +RX Burst Size +^ + +As vPMD is focused on high throughput, it 4 packets at a time. So it assumes +that the RX burst should be greater than 4 per burst. It returns zero if using +``nb_pkt`` < 4 in the receive handler. If ``nb_pkt`` is not multiple of 4, a +floor alignment will be applied. + + +TX Constraint +~ + +Features not Supported by TX Vector PMD +^^^ + +TX vPMD only works when ``txq_flags`` is set to ``FM10K_SIMPLE_TX_FLAG``. +This means that it does not support TX multi-segment, VLAN offload or TX csum +offload. The following MACROs are used for these three features: + +* ``ETH_TXQ_FLAGS_NOMULTSEGS`` + +* ``ETH_TXQ_FLAGS_NOVLANOFFL`` + +* ``ETH_TXQ_FLAGS_NOXSUMSCTP`` + +* ``ETH_TXQ_FLAGS_NOXSUMUDP`` + +* ``ETH_TXQ_FLAGS_NOXSUMTCP`` + Limitations --- -- 1.7.7.6
[dpdk-dev] [PATCH v2] fm10k: fix switch manager high CPU usage
Hi, Best Regards, Mark > -Original Message- > From: He, Shaopeng > Sent: Thursday, February 04, 2016 8:45 PM > To: dev at dpdk.org > Cc: Chen, Jing D; Wang, Xiao W; He, Shaopeng > Subject: [PATCH v2] fm10k: fix switch manager high CPU usage > > fm10k switch core uses source MAC + VID + SGLORT to do > look up in MAC table. If no match, an exception interrupt > will be sent to the switch manager. Too much of this kind > of exception interrupts cause switch manager side high CPU > usage. > To reproduce this issue, one DPDK testpmd runs on a server > with one fm10k NIC, mac forwards test traffic from one of > fm10k ports to another port. The CPU usage for the switch > manager will go up to about 20% for test traffic rate at > 10G bps, comparing to near 0% for no test traffic. > This patch fixes this issue. A default SGLORT is assigned > to each TX queue. This default value works for non-VMDq mode > and current VMDq example. For advanced VMDq usage, e.g. > different source MAC address for different TX queue, FTAG > forwarding function could be used to change this default > SGLORT value. > > Signed-off-by: Shaopeng He Acked-by: Jing Chen
[dpdk-dev] [PATCH v2] fm10k: enable PCIe port level Loopback Suppression
Hi, Best Regards, Mark > -Original Message- > From: He, Shaopeng > Sent: Thursday, February 04, 2016 8:43 PM > To: dev at dpdk.org > Cc: Chen, Jing D; Wang, Xiao W; He, Shaopeng > Subject: [PATCH v2] fm10k: enable PCIe port level Loopback Suppression > > In FM10K, a single PCIe port can derive out a few logical ports, > like SRIOV PF/VF devices, VMDQ objects. To better manage them, FM10K > silicon assigned a Unique GLORT ID to each logical ports. > When a logical port sends a broadcast packet, the silicon will flood > it to all Logical ports, including the one sent the broadcast packet. > To prevent this, silicon has a rxq register to fill the glort id of > the logical port that queue binds to. > FM10K has a switch core inside, which has another loopback suppression > mechanism in the switch level. Switch level loopback suppression mostly > works for the ether port traffic. > This patch assigns a SGLORT for each RX queue, and enables PCIe port > level Loopback Suppression. > > Signed-off-by: Shaopeng He Acked-by : Jing Chen
[dpdk-dev] [PATCH v3 0/3] fm10k: enable FTAG based forwarding
Hi, Best Regards, Mark > -Original Message- > From: Wang, Xiao W > Sent: Thursday, February 04, 2016 11:39 AM > To: Chen, Jing D > Cc: dev at dpdk.org; Qiu, Michael; He, Shaopeng; Wang, Xiao W > Subject: [PATCH v3 0/3] fm10k: enable FTAG based forwarding > > v3: > * Removed "\n" in PMD_INIT_LOG. > > * Returned "-ENOTSUP" instead of -1 in VF FTAG use case. > > v2: > * Gave an error message for VF FTAG use case. > > * Added a notice in the doc to emphasize that application should ensure > an appropriate FTAG for every frame in FTAG based forwarding mode. > > Wang Xiao W (3): > fm10k: enable FTAG based forwarding > doc: add introduction for fm10k FTAG based forwarding > doc: update release note for fm10k FTAG support > > config/common_bsdapp | 1 + > config/common_linuxapp | 1 + > doc/guides/nics/fm10k.rst| 16 +++- > doc/guides/rel_notes/release_2_3.rst | 1 + > drivers/net/fm10k/fm10k_ethdev.c | 12 > drivers/net/fm10k/fm10k_rxtx.c | 17 + > drivers/net/fm10k/fm10k_rxtx_vec.c | 9 + > 7 files changed, 56 insertions(+), 1 deletion(-) > > -- > 1.9.3 Acked-by: Jing Chen
[dpdk-dev] [PATCH 1/2 v2] fm10k: Add Atwood Channel Support
Hi, Best Regards, Mark > -Original Message- > From: Qiu, Michael > Sent: Thursday, February 04, 2016 4:36 PM > To: dev at dpdk.org > Cc: Chen, Jing D; Qiu, Michael > Subject: [PATCH 1/2 v2] fm10k: Add Atwood Channel Support > > Atwood Channel is intel 25G NIC, and this patch add the support > in DPDK. > > Signed-off-by: Michael Qiu > Acked-by: John McNamara Acked-by: Jing Chen
[dpdk-dev] [PATCH 2/2] fm10k: update doc for Atwood Channel
Hi, Best Regards, Mark > -Original Message- > From: Qiu, Michael > Sent: Monday, January 11, 2016 3:28 PM > To: dev at dpdk.org > Cc: Chen, Jing D; Qiu, Michael > Subject: [PATCH 2/2] fm10k: update doc for Atwood Channel > > Atwood Channel is 20GbE NIC and belongs to Intel FM10K family, > update the doc for it. There is a typo above. It's 25G, not 20. > > Signed-off-by: Michael Qiu > --- > doc/guides/rel_notes/release_2_3.rst | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/doc/guides/rel_notes/release_2_3.rst > b/doc/guides/rel_notes/release_2_3.rst > index 99de186..7dd9c0f 100644 > --- a/doc/guides/rel_notes/release_2_3.rst > +++ b/doc/guides/rel_notes/release_2_3.rst > @@ -3,7 +3,9 @@ DPDK Release 2.3 > > New Features > > +* **New NIC Atwood Channel support.** > > + Added support for the Atwood Channel variant of Intel's fm10k NIC family. > > Resolved Issues > --- > -- > 1.9.3
[dpdk-dev] [PATCH] fm10k: fix switch manager high CPU usage
Hi, Best Regards, Mark > -Original Message- > From: He, Shaopeng > Sent: Thursday, January 28, 2016 1:47 PM > To: dev at dpdk.org > Cc: Chen, Jing D; Wang, Xiao W; He, Shaopeng > Subject: [PATCH] fm10k: fix switch manager high CPU usage > > fm10k switch core uses source MAC + VID + SGLORT to do > look up in MAC table. If no match, an exception interrupt > will be sent to the switch manager, and cause high CPU > usage. Above paragraph didn't describe the bug clearly. Can you add more Words on it? > This patch fixes this issue. A default SGLORT is assigned > to each TX queue. This default value works for non-VMDq mode > and current VMDq example. For advanced VMDq usage, e.g. > different source MAC address for different TX queue, FTAG > forwarding function could be used to change this default > SGLORT value. > > Signed-off-by: Shaopeng He > --- > drivers/net/fm10k/fm10k_ethdev.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/net/fm10k/fm10k_ethdev.c > b/drivers/net/fm10k/fm10k_ethdev.c > index e4aed94..f6eb05d 100644 > --- a/drivers/net/fm10k/fm10k_ethdev.c > +++ b/drivers/net/fm10k/fm10k_ethdev.c > @@ -675,6 +675,9 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev) > FM10K_WRITE_REG(hw, FM10K_TDBAH(i), > base_addr >> (CHAR_BIT * sizeof(uint32_t))); > FM10K_WRITE_REG(hw, FM10K_TDLEN(i), size); > + > + /* assign default SGLORT for each TX queue */ > + FM10K_WRITE_REG(hw, FM10K_TX_SGLORT(i), hw- > >mac.dglort_map); > } > > /* set up vector or scalar TX function as appropriate */ > -- > 1.9.3
[dpdk-dev] [PATCH] fm10k: enable PCIe port level Loopback Suppression
Hi, Best Regards, Mark > -Original Message- > From: He, Shaopeng > Sent: Thursday, January 28, 2016 1:49 PM > To: dev at dpdk.org > Cc: Chen, Jing D; Wang, Xiao W; He, Shaopeng > Subject: [PATCH] fm10k: enable PCIe port level Loopback Suppression > > A PCIe port may represent within it multiple logical ports > (for example when SR-IOV is enabled, or when a VMDQ type logical > port scheme is employed assigning ports to sets of queues). > For this reason each RX queue in each PCIe port is given a source > GLORT that is used for loopback suppression. > This patch assigns a SGLORT for each RX queue, and enables PCIe > port level Loopback Suppression. > The log message is a little obscure for me. Maybe you can wrote: In FM10K, a single PF device can derive out a few logical ports, like SRIOV VF device, VMDQ object. To better manage them, FM10K silicon assigned a Unique GLORT ID to each logical ports. When a logical port sends a broadcast packet, the silicon will flood it to all Logical ports, including the one sent the broadcast packet. To prevent this, silicon has a rxq register to fill the glort id of the logical port that queue binds to > Signed-off-by: Shaopeng He > --- > drivers/net/fm10k/fm10k_ethdev.c | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/fm10k/fm10k_ethdev.c > b/drivers/net/fm10k/fm10k_ethdev.c > index f6eb05d..60f821a 100644 > --- a/drivers/net/fm10k/fm10k_ethdev.c > +++ b/drivers/net/fm10k/fm10k_ethdev.c > @@ -690,12 +690,15 @@ static int > fm10k_dev_rx_init(struct rte_eth_dev *dev)
[dpdk-dev] [PATCH v2 1/3] fm10k: enable FTAG based forwarding
Hi,
Best Regards,
Mark
> -Original Message-
> From: Wang, Xiao W
> Sent: Tuesday, February 02, 2016 6:50 PM
> To: Chen, Jing D
> Cc: dev at dpdk.org; Qiu, Michael; He, Shaopeng; Wang, Xiao W
> Subject: [PATCH v2 1/3] fm10k: enable FTAG based forwarding
>
> This patch enables reading sglort info into mbuf for RX and inserting
> an FTAG at the beginning of the packet for TX. The vlan_tci_outer field
> selected from rte_mbuf structure for sglort is not used in fm10k now.
> In FTAG based forwarding mode, the switch will forward packets according
> to glort info in FTAG rather than mac and vlan table.
>
> To activate this feature, user needs to turn
> ``CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD``
> to y in common_linuxapp or common_bsdapp. Currently this feature is
> supported
> only on PF, because FM10K_PFVTCTL register is read-only for VF.
>
> Signed-off-by: Wang Xiao W
> ---
> config/common_bsdapp | 1 +
> config/common_linuxapp | 1 +
> drivers/net/fm10k/fm10k_ethdev.c | 12
> drivers/net/fm10k/fm10k_rxtx.c | 17 +
> drivers/net/fm10k/fm10k_rxtx_vec.c | 9 +
> 5 files changed, 40 insertions(+)
>
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index ed7c31c..451f81a 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -208,6 +208,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX=n
> CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
>
> #
> # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 74bc515..c928bce 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -207,6 +207,7 @@ CONFIG_RTE_LIBRTE_FM10K_DEBUG_TX_FREE=n
> CONFIG_RTE_LIBRTE_FM10K_DEBUG_DRIVER=n
> CONFIG_RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE=y
> CONFIG_RTE_LIBRTE_FM10K_INC_VECTOR=y
> +CONFIG_RTE_LIBRTE_FM10K_FTAG_FWD=n
>
> #
> # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> b/drivers/net/fm10k/fm10k_ethdev.c
> index e4aed94..3a15c24 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -668,6 +668,18 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
> PMD_INIT_LOG(ERR, "failed to disable queue %d", i);
> return -1;
> }
> +#ifdef RTE_LIBRTE_FM10K_FTAG_FWD
> + /* Enable use of FTAG bit in TX descriptor, PFVTCTL
> + * register is read-only for VF.
> + */
> + if (hw->mac.type == fm10k_mac_pf)
> + FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
> +
> FM10K_PFVTCTL_FTAG_DESC_ENABLE);
> + else {
> + PMD_INIT_LOG(ERR, "FTAG is not supported in
> VF.\n");
"\n" is not necessary.
> + return -1;
Return "-ENOTSUP"?
> + }
> +#endif
>
> /* set location and size for descriptor ring */
> FM10K_WRITE_REG(hw, FM10K_TDBAL(i),
[dpdk-dev] [PATCH] fm10k: handle err flags in vector RX func
From: "Chen Jing D(Mark)"
Using SSE instructions to parse error flags in HW Rx descriptor,
then set corresponding bits of mbuf.
Signed-off-by: Chen Jing D(Mark)
---
doc/guides/rel_notes/release_2_3.rst |2 +
drivers/net/fm10k/fm10k_rxtx_vec.c | 42 +-
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst
b/doc/guides/rel_notes/release_2_3.rst
index 99de186..19e8aa2 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -3,7 +3,9 @@ DPDK Release 2.3
New Features
+* **Handle error flags in fm10k vector RX func**
+ * Parse err flags in Rx desc and set error bits in mbuf with vector
instructions.
Resolved Issues
---
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 2a57eef..0c48a48 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -61,11 +61,17 @@ fm10k_reset_tx_queue(struct fm10k_tx_queue *txq);
#define L3TYPE_SHIFT (4)
/* L4 type shift */
#define L4TYPE_SHIFT (7)
+/* HBO flag shift */
+#define HBOFLAG_SHIFT (10)
+/* RXE flag shift */
+#define RXEFLAG_SHIFT (13)
+/* IPE/L4E flag shift */
+#define L3L4EFLAG_SHIFT (14)
static inline void
fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf **rx_pkts)
{
- __m128i ptype0, ptype1, vtag0, vtag1;
+ __m128i ptype0, ptype1, vtag0, vtag1, eflag0, eflag1, cksumflag;
union {
uint16_t e[4];
uint64_t dword;
@@ -81,12 +87,29 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
**rx_pkts)
0x, 0x, 0x, 0x,
0x000F, 0x000F, 0x000F, 0x000F);
+ /* mask for HBO and RXE flag flags */
+ const __m128i rxe_msk = _mm_set_epi16(
+ 0x, 0x, 0x, 0x,
+ 0x0001, 0x0001, 0x0001, 0x0001);
+
+ const __m128i l3l4cksum_flag = _mm_set_epi8(0, 0, 0, 0,
+ 0, 0, 0, 0,
+ 0, 0, 0, 0,
+ PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD,
+ PKT_RX_IP_CKSUM_BAD, PKT_RX_L4_CKSUM_BAD, 0);
+
+ const __m128i rxe_flag = _mm_set_epi8(0, 0, 0, 0,
+ 0, 0, 0, 0,
+ 0, 0, 0, 0,
+ 0, 0, PKT_RX_RECIP_ERR, 0);
+
/* map rss type to rss hash flag */
const __m128i rss_flags = _mm_set_epi8(0, 0, 0, 0,
0, 0, 0, PKT_RX_RSS_HASH,
PKT_RX_RSS_HASH, 0, PKT_RX_RSS_HASH, 0,
PKT_RX_RSS_HASH, PKT_RX_RSS_HASH, PKT_RX_RSS_HASH, 0);
+ /* Calculate RSS_hash and Vlan fields */
ptype0 = _mm_unpacklo_epi16(descs[0], descs[1]);
ptype1 = _mm_unpacklo_epi16(descs[2], descs[3]);
vtag0 = _mm_unpackhi_epi16(descs[0], descs[1]);
@@ -97,10 +120,27 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
**rx_pkts)
ptype0 = _mm_shuffle_epi8(rss_flags, ptype0);
vtag1 = _mm_unpacklo_epi32(vtag0, vtag1);
+ eflag0 = vtag1;
+ cksumflag = vtag1;
vtag1 = _mm_srli_epi16(vtag1, VP_SHIFT);
vtag1 = _mm_and_si128(vtag1, pkttype_msk);
vtag1 = _mm_or_si128(ptype0, vtag1);
+
+ /* Process err flags, simply set RECIP_ERR bit if HBO/IXE is set */
+ eflag1 = _mm_srli_epi16(eflag0, RXEFLAG_SHIFT);
+ eflag0 = _mm_srli_epi16(eflag0, HBOFLAG_SHIFT);
+ eflag0 = _mm_or_si128(eflag0, eflag1);
+ eflag0 = _mm_and_si128(eflag1, rxe_msk);
+ eflag0 = _mm_shuffle_epi8(rxe_flag, eflag0);
+
+ vtag1 = _mm_or_si128(eflag0, vtag1);
+
+ /* Process L4/L3 checksum error flags */
+ cksumflag = _mm_srli_epi16(cksumflag, L3L4EFLAG_SHIFT);
+ cksumflag = _mm_shuffle_epi8(l3l4cksum_flag, cksumflag);
+ vtag1 = _mm_or_si128(cksumflag, vtag1);
+
vol.dword = _mm_cvtsi128_si64(vtag1);
rx_pkts[0]->ol_flags = vol.e[0];
--
1.7.7.6
