search for: tx_timeo

...: > > > 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 reason. To > > > enable it, driver should have .ndo_tx_timeout implemented. > > > > > > This commit brings back virtnet_reset method to recover TX queues from a > > > error state. That function is called by schedule_work method and it puts > > > the reset function into work queue. > > > > > > As the error...

...; 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 reason. To > > > > enable it, driver should have .ndo_tx_timeout implemented. > > > > > > > > This commit brings back virtnet_reset method to recover TX queues from a > > > > error state. That function is called by schedule_work method and it puts > > > > the reset function into work queue. > > > > &g...

...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 reason. To > > enable it, driver should have .ndo_tx_timeout implemented. > > > > This commit brings back virtnet_reset method to recover TX queues from a > > error state. That function is called by schedule_work method and it puts > > the reset function into work queue. > > > > As the error cause is unknown at this mome...

...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 reason. To > > enable it, driver should have .ndo_tx_timeout implemented. > > > > This commit brings back virtnet_reset method to recover TX queues from a > > error state. That function is called by schedule_work method and it puts > > the reset function into work queue. > > > > As the error cause is unknown at this mome...

...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: #/usr/bin/perl 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"], ["arch/um/drivers/vector_kern.c", "vector_net_tx_timeout"], ["arch/xtensa/platforms/iss/network.c", "iss_net_tx_timeout"], ["drivers/char/pcmcia/synclink_cs.c", &quo...

...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: #/usr/bin/perl 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"], ["arch/um/drivers/vector_kern.c", "vector_net_tx_timeout"], ["arch/xtensa/platforms/iss/network.c", "iss_net_tx_timeout"], ["drivers/char/pcmcia/synclink_cs.c", &quo...

...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: #/usr/bin/perl 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"], ["arch/um/drivers/vector_kern.c", "vector_net_tx_timeout"], ["arch/xtensa/platforms/iss/network.c", "iss_net_tx_timeout"], ["drivers/char/pcmcia/synclink_cs.c", &quo...

...> > 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, struct net_device *dev) > > return 0; > > } > > > > -static void nfeth_tx_timeout(struct net_device *dev) > > +static void nfeth_tx_timeout(struct net_device *dev, int txqueue) > > Given the recent vf ndo problems, I wonder if it's worth making the > queue id unsigned from the start? Since it's coming from the stack > there should be no range checkin...

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>

...n 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"], > > ["arch/um/drivers/vector_kern.c", "vector_net_tx_timeout"], > > ["arch/xtensa/platforms/iss/network.c", "iss_net_tx_timeout"], > > ["drive...

...ows 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"], ["arch/um/drivers/vector_kern.c", "vector_net_tx_timeout"], ["arch/xtensa/platforms/iss/network.c", "iss_net_tx_timeout"], ["drivers/char/pcmcia/synclink_cs.c", &quo...

...ows 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"], ["arch/um/drivers/vector_kern.c", "vector_net_tx_timeout"], ["arch/xtensa/platforms/iss/network.c", "iss_net_tx_timeout"], ["drivers/char/pcmcia/synclink_cs.c", &quo...

...ows 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"], ["arch/um/drivers/vector_kern.c", "vector_net_tx_timeout"], ["arch/xtensa/platforms/iss/network.c", "iss_net_tx_timeout"], ["drivers/char/pcmcia/synclink_cs.c", &quo...

...ows 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"], ["arch/um/drivers/vector_kern.c", "vector_net_tx_timeout"], ["arch/xtensa/platforms/iss/network.c", "iss_net_tx_timeout"], ["drivers/char/pcmcia/synclink_cs.c", &quo...

...ows 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"], ["arch/um/drivers/vector_kern.c", "vector_net_tx_timeout"], ["arch/xtensa/platforms/iss/network.c", "iss_net_tx_timeout"], ["drivers/char/pcmcia/synclink_cs.c", &quo...

This series add two important features. One of them changes the .ndo_tx_timeout to include an extra parameter to identify the stuck queue. Many drivers are using a nester loop to identify which queue is stooped/stucked. This is a redundant work since dev_watchdog is doing exactly the same thing. This is so interesting for other drivers to in terms of code optimization. The...

This series add two important features. One of them changes the .ndo_tx_timeout to include an extra parameter to identify the stuck queue. Many drivers are using a nester loop to identify which queue is stooped/stucked. This is a redundant work since dev_watchdog is doing exactly the same thing. This is so interesting for other drivers to in terms of code optimization. The...

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

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.