similar to: [vhost:linux-next 4/11] drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1376:12: error: 'tx_ring' undeclared; did you mean 'en_print'?

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c index aa348230bd39..2c2ff1f0ea6d 100644 --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c +++

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c index aa348230bd39..2c2ff1f0ea6d 100644 --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c +++

On Fri, Nov 22, 2019 at 09:59:58AM -0300, Julio Faracco wrote: > Hi Michael, > > Em sex., 22 de nov. de 2019 ?s 07:31, Michael S. Tsirkin > <mst at redhat.com> escreveu: > > > > On Thu, Nov 21, 2019 at 10:36:36PM -0300, Julio Faracco wrote: > > > Driver virtio_net is not handling error events for TX provided by > > > dev_watchdog. This event is

Em sex., 22 de nov. de 2019 ?s 11:53, Michael S. Tsirkin <mst at redhat.com> escreveu: > > On Fri, Nov 22, 2019 at 09:59:58AM -0300, Julio Faracco wrote: > > Hi Michael, > > > > Em sex., 22 de nov. de 2019 ?s 07:31, Michael S. Tsirkin > > <mst at redhat.com> escreveu: > > > > > > On Thu, Nov 21, 2019 at 10:36:36PM -0300, Julio Faracco

On Fri, Nov 22, 2019 at 09:59:58AM -0300, Julio Faracco wrote: > I need your help with debbuging information. What kind of field shoud > it notify when a TX timeout occurs? So here's v2. Still untested. ---> netdev: pass the stuck queue to the timeout handler This allows incrementing the correct timeout statistic without any mess. Down the road, devices can learn to reset just the

Em qua., 27 de nov. de 2019 ?s 12:12, Martin Habets <mhabets at solarflare.com> escreveu: > > Your @work correctly identifies that the drivers/net/ethernet/sfc drivers need patching, but the actual patches for them are missing. > Please add those. Makes me wonder if any other files are missing patches. Since, I'm adding new stuffs to virtion_net (2/2), I will split this into a

On Sun, Nov 24, 2019 at 03:03:52PM -0800, Jakub Kicinski wrote: > On Sun, 24 Nov 2019 16:48:35 -0500, Michael S. Tsirkin wrote: > > diff --git a/arch/m68k/emu/nfeth.c b/arch/m68k/emu/nfeth.c > > index a4ebd2445eda..8e06e7407854 100644 > > --- a/arch/m68k/emu/nfeth.c > > +++ b/arch/m68k/emu/nfeth.c > > @@ -167,7 +167,7 @@ static int nfeth_xmit(struct sk_buff *skb,

This allows incrementing the correct timeout statistic without any mess. Down the road, devices can learn to reset just the specific queue. The patch was generated with the following script: use strict; use warnings; our $^I = '.bak'; my @work = ( ["arch/m68k/emu/nfeth.c", "nfeth_tx_timeout"], ["arch/um/drivers/net_kern.c", "uml_net_tx_timeout"],

This allows incrementing the correct timeout statistic without any mess. Down the road, devices can learn to reset just the specific queue. The patch was generated with the following script: use strict; use warnings; our $^I = '.bak'; my @work = ( ["arch/m68k/emu/nfeth.c", "nfeth_tx_timeout"], ["arch/um/drivers/net_kern.c", "uml_net_tx_timeout"],

This allows incrementing the correct timeout statistic without any mess. Down the road, devices can learn to reset just the specific queue. The patch was generated with the following script: use strict; use warnings; our $^I = '.bak'; my @work = ( ["arch/m68k/emu/nfeth.c", "nfeth_tx_timeout"], ["arch/um/drivers/net_kern.c", "uml_net_tx_timeout"],

This allows incrementing the correct timeout statistic without any mess. Down the road, devices can learn to reset just the specific queue. The patch was generated with the following script: use strict; use warnings; our $^I = '.bak'; my @work = ( ["arch/m68k/emu/nfeth.c", "nfeth_tx_timeout"], ["arch/um/drivers/net_kern.c", "uml_net_tx_timeout"],

This allows incrementing the correct timeout statistic without any mess. Down the road, devices can learn to reset just the specific queue. The patch was generated with the following script: use strict; use warnings; our $^I = '.bak'; my @work = ( ["arch/m68k/emu/nfeth.c", "nfeth_tx_timeout"], ["arch/um/drivers/net_kern.c", "uml_net_tx_timeout"],

Thank you for your mail. ibv_rc_pingpong seems working between servers and client. Also udaddy, ucmatose, rping etc are working. root at gluster1:~# ibv_rc_pingpong -d mlx5_0 -g 0 ? local address:? LID 0x0000, QPN 0x0001e4, PSN 0x10090e, GID fe80::ee0d:9aff:fec0:1dc8 ? remote address: LID 0x0000, QPN 0x00014c, PSN 0x09402b, GID fe80::ee0d:9aff:fec0:1b14 8192000 bytes in 0.01 seconds =

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Acked-by: Jakub Kicinski <jakub.kicinski at netronome.com> --- drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c index 41a808b14d76..eb1f9bed4833

Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Acked-by: Jakub Kicinski <jakub.kicinski at netronome.com> --- drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c index 41a808b14d76..eb1f9bed4833

On Sun, Nov 24, 2019 at 10:05:54AM -0500, Michael S. Tsirkin wrote: > On Fri, Nov 22, 2019 at 09:59:58AM -0300, Julio Faracco wrote: > > I need your help with debbuging information. What kind of field shoud > > it notify when a TX timeout occurs? > > So here's v2. OK this still missed a couple of things. Here's another one - still untested. One good thing is this is

On Sun, Nov 24, 2019 at 10:05:54AM -0500, Michael S. Tsirkin wrote: > On Fri, Nov 22, 2019 at 09:59:58AM -0300, Julio Faracco wrote: > > I need your help with debbuging information. What kind of field shoud > > it notify when a TX timeout occurs? > > So here's v2. OK this still missed a couple of things. Here's another one - still untested. One good thing is this is

This patch adds support for virtual IOMMU to the vmxnet3 module. We switch to DMA consistent mappings for anything we pass to the device. There were a few places where we already did this, but using pci_blah(); these have been fixed to use dma_blah(), along with all new occurrences where we've replaced kmalloc() and friends. Also fix two small bugs: 1) use after free of rq->buf_info in

This patch adds support for virtual IOMMU to the vmxnet3 module. We switch to DMA consistent mappings for anything we pass to the device. There were a few places where we already did this, but using pci_blah(); these have been fixed to use dma_blah(), along with all new occurrences where we've replaced kmalloc() and friends. Also fix two small bugs: 1) use after free of rq->buf_info in

On 2020/7/16 ??3:23, Eli Cohen wrote: > Add a front end VDPA driver that registers in the VDPA bus and provides > networking to a guest. The VDPA driver creates the necessary resources > on the VF it is driving such that data path will be offloaded. > > Notifications are being communicated through the driver. > > Currently, only VFs are supported. In subsequent patches we will