| Message ID | 20181214012621.15213-4-stephen@networkplumber.org (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Delegated to: | Ferruh Yigit |
| Headers | show |
| Series | net/netvsc: misc fixes | expand |
| Context | Check | Description |
|---|---|---|
| ci/checkpatch | warning | coding style issues |
| ci/Intel-compilation | success | Compilation OK |
On 12/14/2018 1:26 AM, Stephen Hemminger wrote: > It is possible that the VF device exists but DPDK doesn't know > about it. This could happen if device was blacklisted or more > likely the necessary device (Mellanox) was not part of the DPDK > configuration. > > In either case, the right thing to do is just keep working > but only with the slower para-virtual device. Same question for this one, is this something that should be backported? Is it intentionally left out from backporting? Just a reminder, for backport, a patch needs a few markers, - fix patch with fixes line - Cc: stable@dpdk.org line > > Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> > --- > drivers/net/netvsc/hn_ethdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c > index de872212d3f3..1f7a7e66a51b 100644 > --- a/drivers/net/netvsc/hn_ethdev.c > +++ b/drivers/net/netvsc/hn_ethdev.c > @@ -788,7 +788,7 @@ eth_hn_dev_init(struct rte_eth_dev *eth_dev) > > err = hn_vf_add(eth_dev, hv); > if (err) > - goto failed; > + hv->vf_present = 0; > } > > return 0; >
On 12/17/2018 7:59 PM, Stephen Hemminger wrote: > This can go to 18.11 stable I will add fixes and stable tags while merging, please provide them with commit to ensure the backport of the patches to the stable trees. > > -----Original Message----- > From: Ferruh Yigit <ferruh.yigit@intel.com> > Sent: Monday, December 17, 2018 2:49 AM > To: Stephen Hemminger <stephen@networkplumber.org>; dev@dpdk.org > Cc: Stephen Hemminger <sthemmin@microsoft.com>; Kevin Traynor <ktraynor@redhat.com> > Subject: Re: [dpdk-dev] [PATCH 3/3] net/netvsc: not finding VF should not cause failure > > On 12/14/2018 1:26 AM, Stephen Hemminger wrote: >> It is possible that the VF device exists but DPDK doesn't know >> about it. This could happen if device was blacklisted or more >> likely the necessary device (Mellanox) was not part of the DPDK >> configuration. >> >> In either case, the right thing to do is just keep working >> but only with the slower para-virtual device. > > Same question for this one, is this something that should be backported? > Is it intentionally left out from backporting? > > Just a reminder, for backport, a patch needs a few markers, > - fix patch with fixes line > - Cc: stable@dpdk.org line > >> >> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> >> --- >> drivers/net/netvsc/hn_ethdev.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c >> index de872212d3f3..1f7a7e66a51b 100644 >> --- a/drivers/net/netvsc/hn_ethdev.c >> +++ b/drivers/net/netvsc/hn_ethdev.c >> @@ -788,7 +788,7 @@ eth_hn_dev_init(struct rte_eth_dev *eth_dev) >> >> err = hn_vf_add(eth_dev, hv); >> if (err) >> - goto failed; >> + hv->vf_present = 0; >> } >> >> return 0; >> >
On 12/17/2018 10:11 PM, Ferruh Yigit wrote: > On 12/17/2018 7:59 PM, Stephen Hemminger wrote: >> This can go to 18.11 stable > > I will add fixes and stable tags while merging, please provide them with commit > to ensure the backport of the patches to the stable trees. Added: Fixes: dc7680e8597c ("net/netvsc: support integrated VF") Cc: stable@dpdk.org > >> >> -----Original Message----- >> From: Ferruh Yigit <ferruh.yigit@intel.com> >> Sent: Monday, December 17, 2018 2:49 AM >> To: Stephen Hemminger <stephen@networkplumber.org>; dev@dpdk.org >> Cc: Stephen Hemminger <sthemmin@microsoft.com>; Kevin Traynor <ktraynor@redhat.com> >> Subject: Re: [dpdk-dev] [PATCH 3/3] net/netvsc: not finding VF should not cause failure >> >> On 12/14/2018 1:26 AM, Stephen Hemminger wrote: >>> It is possible that the VF device exists but DPDK doesn't know >>> about it. This could happen if device was blacklisted or more >>> likely the necessary device (Mellanox) was not part of the DPDK >>> configuration. >>> >>> In either case, the right thing to do is just keep working >>> but only with the slower para-virtual device. >> >> Same question for this one, is this something that should be backported? >> Is it intentionally left out from backporting? >> >> Just a reminder, for backport, a patch needs a few markers, >> - fix patch with fixes line >> - Cc: stable@dpdk.org line >> >>> >>> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> >>> --- >>> drivers/net/netvsc/hn_ethdev.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c >>> index de872212d3f3..1f7a7e66a51b 100644 >>> --- a/drivers/net/netvsc/hn_ethdev.c >>> +++ b/drivers/net/netvsc/hn_ethdev.c >>> @@ -788,7 +788,7 @@ eth_hn_dev_init(struct rte_eth_dev *eth_dev) >>> >>> err = hn_vf_add(eth_dev, hv); >>> if (err) >>> - goto failed; >>> + hv->vf_present = 0; >>> } >>> >>> return 0; >>> >> >
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c index de872212d3f3..1f7a7e66a51b 100644 --- a/drivers/net/netvsc/hn_ethdev.c +++ b/drivers/net/netvsc/hn_ethdev.c @@ -788,7 +788,7 @@ eth_hn_dev_init(struct rte_eth_dev *eth_dev) err = hn_vf_add(eth_dev, hv); if (err) - goto failed; + hv->vf_present = 0; } return 0;
It is possible that the VF device exists but DPDK doesn't know about it. This could happen if device was blacklisted or more likely the necessary device (Mellanox) was not part of the DPDK configuration. In either case, the right thing to do is just keep working but only with the slower para-virtual device. Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com> --- drivers/net/netvsc/hn_ethdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)