> -----Original Message----- > From: Eric Dumazet [mailto:eric.dumazet@xxxxxxxxx] > Sent: Wednesday, May 6, 2015 12:18 PM > To: KY Srinivasan > Cc: davem@xxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; > apw@xxxxxxxxxxxxx; jasowang@xxxxxxxxxx > 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 devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
