similar to: [PATCH net-next] virtio: change comment in transmit

Stephen Hemminger <stephen at networkplumber.org> writes: > The original comment was not really informative or funny > as well as sexist. Replace it with a better explanation of > why the driver does stop and what the impacts are. > > Signed-off-by: Stephen Hemminger <stephen at networkplumber.org> Fair call. Comment was certainly snarky, probably sexist. I think it

Stephen Hemminger <stephen at networkplumber.org> writes: > The original comment was not really informative or funny > as well as sexist. Replace it with a better explanation of > why the driver does stop and what the impacts are. > > Signed-off-by: Stephen Hemminger <stephen at networkplumber.org> Fair call. Comment was certainly snarky, probably sexist. I think it

commit d631b94e7a15277858ec5f88d674d93080506999 virtio: change comment in transmit started clarifying the logic behind queue state management, but introduced an inaccuracy: TX_BUSY does not cause a BUG message. Clean this up some more, explaining the tradeoffs in detail. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- diff --git a/drivers/net/virtio_net.c

commit d631b94e7a15277858ec5f88d674d93080506999 virtio: change comment in transmit started clarifying the logic behind queue state management, but introduced an inaccuracy: TX_BUSY does not cause a BUG message. Clean this up some more, explaining the tradeoffs in detail. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- diff --git a/drivers/net/virtio_net.c

The virtio_net driver never sends the multicast address list to the host. This is because send command takes a pointer to scatter list to send but only inserts that one entry into the outgoing scatter list. This bug has been there since: commit f565a7c259d71cc186753653d978c646d2354b36 Author: Alex Williamson <alex.williamson at hp.com> Date: Wed Feb 4 09:02:45 2009 +0000 virtio_net:

The virtio_net driver never sends the multicast address list to the host. This is because send command takes a pointer to scatter list to send but only inserts that one entry into the outgoing scatter list. This bug has been there since: commit f565a7c259d71cc186753653d978c646d2354b36 Author: Alex Williamson <alex.williamson at hp.com> Date: Wed Feb 4 09:02:45 2009 +0000 virtio_net:

On 2014/12/1 18:17, Jason Wang wrote: > On newer hosts that support delayed tx interrupts, > we probably don't have much to gain from orphaning > packets early. > > Note: this might degrade performance for > hosts without event idx support. > Should be addressed by the next patch. > > Cc: Rusty Russell <rusty at rustcorp.com.au> > Cc: Michael S. Tsirkin

On 2014/12/1 18:17, Jason Wang wrote: > On newer hosts that support delayed tx interrupts, > we probably don't have much to gain from orphaning > packets early. > > Note: this might degrade performance for > hosts without event idx support. > Should be addressed by the next patch. > > Cc: Rusty Russell <rusty at rustcorp.com.au> > Cc: Michael S. Tsirkin

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this will likely degrade performance for hosts without event idx support. Various fallback options are available, including orphaning conditionally. Testing TBD. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this will likely degrade performance for hosts without event idx support. Various fallback options are available, including orphaning conditionally. Testing TBD. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

From: Stephen Hemminger <stephen at networkplumber.org> Date: Tue, 19 Dec 2017 09:55:48 -0800 > could be 10ms, just enough to let udev do its renaming Please, move to some kind of notification or event based handling of this problem. No delay is safe, what if userspace gets swapped out or whatever else might make userspace stall unexpectedly?

From: Stephen Hemminger <stephen at networkplumber.org> Date: Tue, 19 Dec 2017 09:55:48 -0800 > could be 10ms, just enough to let udev do its renaming Please, move to some kind of notification or event based handling of this problem. No delay is safe, what if userspace gets swapped out or whatever else might make userspace stall unexpectedly?

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this might degrade performance for hosts without event idx support. Should be addressed by the next patch. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 137

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this might degrade performance for hosts without event idx support. Should be addressed by the next patch. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 137

When fail, translate_desc() returns negative value, otherwise the number of iovs. So we should fail when the return value is negative instead of a blindly check against zero. Reported-by: Stephen Hemminger <stephen at networkplumber.org> Fixes: cc5e71075947 ("vhost: log dirty page correctly") Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 2

When fail, translate_desc() returns negative value, otherwise the number of iovs. So we should fail when the return value is negative instead of a blindly check against zero. Reported-by: Stephen Hemminger <stephen at networkplumber.org> Fixes: cc5e71075947 ("vhost: log dirty page correctly") Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 2

On 12/19/2017 7:47 AM, Michael S. Tsirkin wrote: > I'll need to look at this more, in particular the feature > bit is missing here. For now one question: > > On Mon, Dec 18, 2017 at 04:40:36PM -0800, Sridhar Samudrala wrote: >> @@ -56,6 +58,8 @@ module_param(napi_tx, bool, 0644); >> */ >> DECLARE_EWMA(pkt_len, 0, 64) >> >> +#define

On 12/19/2017 7:47 AM, Michael S. Tsirkin wrote: > I'll need to look at this more, in particular the feature > bit is missing here. For now one question: > > On Mon, Dec 18, 2017 at 04:40:36PM -0800, Sridhar Samudrala wrote: >> @@ -56,6 +58,8 @@ module_param(napi_tx, bool, 0644); >> */ >> DECLARE_EWMA(pkt_len, 0, 64) >> >> +#define

I had Asterisk 1.6.2.2 running fine with a mISDN using a HFC-S based card. I installed my TDM400P into the PC, it's really slow to boot now, when it finally does I gets stuck in a loop of reporting "isac xdu no tx_busy". Anyone able to assist? Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Mon, Dec 01, 2014 at 06:17:04PM +0800, Jason Wang wrote: > On newer hosts that support delayed tx interrupts, > we probably don't have much to gain from orphaning > packets early. > > Note: this might degrade performance for > hosts without event idx support. > Should be addressed by the next patch. > > Cc: Rusty Russell <rusty at rustcorp.com.au> > Cc: