LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jason Wang <firstname.lastname@example.org>
To: Haiyang Zhang <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>,
KY Srinivasan <firstname.lastname@example.org>,
Subject: RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()
Date: Wed, 04 Feb 2015 07:37:12 +0008 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <BN1PR0301MB077018D4A512E3AA9B8583E0CA3D0@BN1PR0301MB0770.namprd03.prod.out look.com>
On Tue, Feb 3, 2015 at 11:46 PM, Haiyang Zhang <firstname.lastname@example.org>
>> -----Original Message-----
>> From: Jason Wang [mailto:email@example.com]
>> Sent: Monday, February 2, 2015 1:49 AM
>> >> btw, I find during netvsc_start_xmit(), ret was change to
>> >> when
>> >> queue_sends[q_idx] < 1. But non of the caller check -ENOSPC in
>> > In this case, we don't request re-send, so set ret to a value
>> > than
>> > -EAGAIN.
>> Why not? We have available slots for it to be sent now. Dropping the
>> packet in this case may cause out of order sending.
> The EAGAIN error doesn't normally happen, because we set the hi water
> to stop send queue.
This is not true since only txq was stopped which means only network
stack stop sending packets but not for control path e.g
rndis_filter_send_request() or other callers who call
vmbus_sendpacket() directly (e.g recv completion).
For control path, user may meet several errors when they want to change
mac address under heavy load.
What's more serious is netvsc_send_recv_completion(), it can not even
recover from more than 3 times of EAGAIN.
I must say mixing data packets with control packets with the same
channel sounds really scary. Since control packets could be blocked or
even dropped because of data packets already queued during heavy load,
and you need to synchronize two paths carefully (e.g I didn't see any
tx lock were held if rndis_filter_send_request() call netsc_send()
which may stop or start a queue).
> If in really rare case, the ring buffer is full and there
> is no outstanding sends, we can't stop queue here because there will
> be no
> send-completion msg to wake it up.
Confused, I believe only txq is stopped but we may still get completion
interrupt in this case.
> And, the ring buffer is likely to be
> occupied by other special msg, e.g. receive-completion msg (not a
> normal case),
> so we can't assume there are available slots.
Then why not checking hv_ringbuf_avail_percent() instead? And there's
no need to check queue_sends since it does not count recv completion.
> We don't request retry from
> the upper layer in this case to avoid possible busy retry.
Can't we just do this by stopping txq and depending on tx interrupt to
next prev parent reply other threads:[~2015-02-04 7:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-29 20:34 Haiyang Zhang
2015-01-30 10:25 ` Jason Wang
2015-01-30 15:05 ` Haiyang Zhang
[not found] ` <BN1PR0301MB0770FCDA58F3BC9E25382D95CA310@BN1PR0301MB0770.namprd03.prod.out look.com>
2015-02-02 6:49 ` Jason Wang
2015-02-03 15:46 ` Haiyang Zhang
[not found] ` <BN1PR0301MB077018D4A512E3AA9B8583E0CA3D0@BN1PR0301MB0770.namprd03.prod.out look.com>
2015-02-04 7:29 ` Jason Wang [this message]
2015-02-04 22:26 ` Haiyang Zhang
2015-02-01 1:32 ` David Miller
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).