From: David Vrabel <david.vrabel@citrix.com>
To: David Miller <davem@redhat.com>, <annie.li@oracle.com>
Cc: <netdev@vger.kernel.org>, <boris.ostrovsky@oracle.com>,
<xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCHv1] xen-netfront: always keep the Rx ring full of requests
Date: Tue, 7 Oct 2014 10:43:36 +0100 [thread overview]
Message-ID: <5433B5C8.9060309@citrix.com> (raw)
In-Reply-To: <20141006.170748.1817067290457286845.davem@redhat.com>
On 06/10/14 22:07, David Miller wrote:
> From: annie li <annie.li@oracle.com>
> Date: Mon, 06 Oct 2014 14:41:48 -0400
>
>>
>> On 2014/10/6 12:00, David Vrabel wrote:
>>>>> + queue->rx.req_prod_pvt = req_prod;
>>>>> +
>>>>> + /* Not enough requests? Try again later. */
>>>>> + if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
>>>>> + mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
>>>>> + return;
>>>> If the previous for loop breaks because of failure of
>>>> xennet_alloc_one_rx_buffer, then notify_remote_via_irq is missed here
>>>> if
>>>> the code returns directly.
>>> This is deliberate -- there's no point notifying the backend if there
>>> aren't enough requests for the next packet. Since we don't know what
>>> the next packet might be we assume it's the largest possible.
>> That makes sense.
>> However, the largest packet case does not happen so
>> frequently. Moreover, netback checks the slots every incoming skb
>> requires in xenvif_rx_ring_slots_available, not only concerning the
>> largest case.
An upcoming change to netback will cause it to wait for enough slots for
the largest possible packet.
> I have an opinion about the sysfs stuff.
>
> It's user facing, so even if it doesn't influence behavior any more
> you have to keep the files around, just make them nops.
That's a good point.
David
next prev parent reply other threads:[~2014-10-07 9:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-02 13:33 [PATCHv1] xen-netfront: always keep the Rx ring full of requests David Vrabel
2014-10-02 13:46 ` [Xen-devel] " Jan Beulich
2014-10-02 13:55 ` David Vrabel
2014-10-02 13:55 ` [Xen-devel] " David Vrabel
2014-10-02 13:46 ` Jan Beulich
2014-10-03 22:54 ` David Miller
2014-10-03 22:54 ` David Miller
2014-10-06 15:35 ` annie li
2014-10-06 15:35 ` [Xen-devel] " annie li
2014-10-06 16:00 ` David Vrabel
2014-10-06 18:41 ` annie li
2014-10-06 18:41 ` [Xen-devel] " annie li
2014-10-06 21:07 ` David Miller
2014-10-06 21:07 ` [Xen-devel] " David Miller
2014-10-07 9:43 ` David Vrabel
2014-10-07 9:43 ` David Vrabel [this message]
2014-10-07 13:12 ` annie li
2014-10-07 13:12 ` [Xen-devel] " annie li
2014-10-06 16:00 ` David Vrabel
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5433B5C8.9060309@citrix.com \
--to=david.vrabel@citrix.com \
--cc=annie.li@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=davem@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.