similar to: [net-next V3 0/2] drivers: net: virtio_net: implement

On Sun, 24 Nov 2019 18:29:49 -0500, Michael S. Tsirkin wrote: > 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 specific queue. FWIW Acked-by: Jakub Kicinski <jakub.kicinski at netronome.com>

A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only. Michael S. Tsirkin (3): netdev: pass the stuck queue to the timeout

Yet another forward declaration I missed. Hopfully the last one ... A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only.

Sorry about the churn, v10 was based on net - not on net-next by mistake. A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only.

Sorry about the churn, v10 was based on net - not on net-next by mistake. A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only.

A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only. Michael S. Tsirkin (3): netdev: pass the stuck queue to the timeout

A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only. Michael S. Tsirkin (3): netdev: pass the stuck queue to the timeout

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 reached when transmission queue is having > > problems to transmit packets. This could happen for any

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 reached when transmission queue is having > > problems to transmit packets. This could happen for any

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

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Danny Kukawka (2): net: replace random_ether_addr() with

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Danny Kukawka (2): net: replace random_ether_addr() with

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Danny Kukawka (2): net: replace random_ether_addr() with

Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. This does that. Compile tested only, but I'd seriously wonder if this broke anything. Suggested-by: Dave Miller <davem at davemloft.net> Signed-off-by: Wilfried Klaebe <w-lkml at lebenslange-mailadresse.de> --- Applies against v3.15-rc4. diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c

Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. This does that. Compile tested only, but I'd seriously wonder if this broke anything. Suggested-by: Dave Miller <davem at davemloft.net> Signed-off-by: Wilfried Klaebe <w-lkml at lebenslange-mailadresse.de> --- Applies against v3.15-rc4. diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c

net: get rid of SET_ETHTOOL_OPS Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. This does that. Mostly done via coccinelle script: @@ struct ethtool_ops *ops; struct net_device *dev; @@ - SET_ETHTOOL_OPS(dev, ops); + dev->ethtool_ops = ops; Compile tested only, but I'd seriously wonder if this broke anything. Suggested-by: Dave Miller <davem at

net: get rid of SET_ETHTOOL_OPS Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. This does that. Mostly done via coccinelle script: @@ struct ethtool_ops *ops; struct net_device *dev; @@ - SET_ETHTOOL_OPS(dev, ops); + dev->ethtool_ops = ops; Compile tested only, but I'd seriously wonder if this broke anything. Suggested-by: Dave Miller <davem at

net: get rid of SET_ETHTOOL_OPS Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. This does that. Mostly done via coccinelle script: @@ struct ethtool_ops *ops; struct net_device *dev; @@ - SET_ETHTOOL_OPS(dev, ops); + dev->ethtool_ops = ops; Compile tested only, but I'd seriously wonder if this broke anything. Suggested-by: Dave Miller <davem at

The second part of my patch series to fix the handling of addr_assign_type for random MAC addresses. This contains the trival changes from random_ether_addr() to new eth_hw_addr_random() and code to reset the state to NET_ADDR_PERM as soon as the MAC get changed via .ndo_set_mac_address where eth_mac_addr wasn't used. Resend due to send with too long recipients list. Sorry! Thanks to Joe