> -----Original Message----- > From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: Wednesday, May 6, 2015 12:18 PM > To: KY Srinivasan > Cc: da...@davemloft.net; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com > Subject: Re: [PATCH V3 net-next 1/1] hv_netvsc: Use the xmit_more skb flag > to optimize signaling the host > > On Wed, 2015-05-06 at 18:28 +0000, KY Srinivasan wrote: > > > Ah! I too was wondering how we could get into this situation. The condition > you mention > > is already handled in the lower level - if the attempt to put the last > > packet > on vmbus were to > > fail because the ring is full, we will notify the host independent of kick_q > parameter - look > > at the function vmbus_sendpacket_ctl() in drivers/hv/channel.c > > > > I will resend the patch by reverting this to version 2. > > I am not really convinced by what you are saying ;) > > problem is not when you fail to add an additional packet. > > Problem is : > > You queue a packet but not kick because skb->xmit_more = 1, and _then_ > you call netif_tx_stop_queue(). > > No further packet will be delivered to your driver, until > netif_tx_wake_queue() is called again from netvsc_send_completion(), > possibly milli seconds later.
Ok; I see your point. We stop the q in our driver under two conditions: 1. When the ring is full and we fail to queue. This situation is taken care of already. 2. We fall below a certain free space in the ring buffer - this is the case you are pointing out. I will address this and resend the patch. Thanks for the review. Regards, K. Y > > If qdisc was replaced by another one, no packet will kick again, unless > other traffic comes. > > Given complexity of your driver, I have no easy way to check you made > this xmit_more conversion correctly, and one packet can not sit in the > equivalent of TX ring buffer for unbound time. > > Better add a full explanation into your changelog. > > _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel