Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1707019 > unrolled thread

Re: [PATCH net] Revert "vhost: cache used event for better performance"

Started byJason Wang <jasowang@redhat.com>
First post2017-08-09 04:40 +0200
Last post2017-08-09 06:40 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH net] Revert "vhost: cache used event for better  performance" Jason Wang <jasowang@redhat.com> - 2017-08-09 04:40 +0200
    Re: [PATCH net] Revert "vhost: cache used event for better  performance" "Michael S. Tsirkin" <mst@redhat.com> - 2017-08-09 06:40 +0200

#1707019 — Re: [PATCH net] Revert "vhost: cache used event for better performance"

FromJason Wang <jasowang@redhat.com>
Date2017-08-09 04:40 +0200
SubjectRe: [PATCH net] Revert "vhost: cache used event for better performance"
Message-ID<ucp4C-Fu-17@gated-at.bofh.it>

On 2017年07月30日 14:26, K. Den wrote:
> On Wed, 2017-07-26 at 19:08 +0300, Michael S. Tsirkin wrote:
>> On Wed, Jul 26, 2017 at 09:37:15PM +0800, Jason Wang wrote:
>>>
>>> On 2017年07月26日 21:18, Jason Wang wrote:
>>>>
>>>> On 2017年07月26日 20:57, Michael S. Tsirkin wrote:
>>>>> On Wed, Jul 26, 2017 at 04:03:17PM +0800, Jason Wang wrote:
>>>>>> This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it
>>>>>> was reported to break vhost_net. We want to cache used event and use
>>>>>> it to check for notification. We try to valid cached used event by
>>>>>> checking whether or not it was ahead of new, but this is not correct
>>>>>> all the time, it could be stale and there's no way to know about this.
>>>>>>
>>>>>> Signed-off-by: Jason Wang<jasowang@redhat.com>
>>>>> Could you supply a bit more data here please?  How does it get stale?
>>>>> What does guest need to do to make it stale?  This will be helpful if
>>>>> anyone wants to bring it back, or if we want to extend the protocol.
>>>>>
>>>> The problem we don't know whether or not guest has published a new used
>>>> event. The check vring_need_event(vq->last_used_event, new + vq->num,
>>>> new) is not sufficient to check for this.
>>>>
>>>> Thanks
>>> More notes, the previous assumption is that we don't move used event back,
>>> but this could happen in fact if idx is wrapper around.
>> You mean if the 16 bit index wraps around after 64K entries.
>> Makes sense.
>>
>>> Will repost and add
>>> this into commit log.
>>>
>>> Thanks
> Hi,

Hi, sorry for the late reply, was on vacation last week.

>
> I am just curious but I have got a question:
> AFAIU, if you wanted to keep the caching mechanism alive in the code base,
> the following two changes could clear off the issue, or not?:
> (1) Always fetch the latest event value from guest when signalled_used event is
> invalid, which includes last_used_idx wraps-around case. Otherwise we might need
> changes which would complicate too much the logic to properly decide whether or
> not to skip signalling in the next vhost_notify round.
> (2) On top of that, split the signal-postponing logic to three cases like:
> * if the interval of vq.num is [2^16, UINT_MAX]:
> any cached event is in should-postpone-signalling interval, so paradoxically
> must always do signalling.

I think don't think current code can work well if vq.num is grater than 
2^15. Since all cached idx is u16. This looks like a bug which needs to 
be fixed.

> * else if the interval of vq.num is [2^15, 2^16):
> the logic in the original patch (809ecb9bca6a9) suffices
> * else (= less than 2^15) (optional):
> checking only (vring_need_event(vq->last_used_event, new + vq->num, new)
> would suffice.
>
> Am I missing something, or is this irrelevant?

Looks not, I think this may work. Let me do some test.

Thanks

> I would appreciate if you could elaborate a bit more how the situation where
> event idx wraps around and moves back would make trouble.
>
> Thanks.
>

[toc] | [next] | [standalone]


#1707054

From"Michael S. Tsirkin" <mst@redhat.com>
Date2017-08-09 06:40 +0200
Message-ID<ucqWJ-1RX-9@gated-at.bofh.it>
In reply to#1707019
On Wed, Aug 09, 2017 at 10:38:10AM +0800, Jason Wang wrote:
> I think don't think current code can work well if vq.num is grater than
> 2^15. Since all cached idx is u16. This looks like a bug which needs to be
> fixed.

That's a limitation of virtio 1.0.

> > * else if the interval of vq.num is [2^15, 2^16):
> > the logic in the original patch (809ecb9bca6a9) suffices
> > * else (= less than 2^15) (optional):
> > checking only (vring_need_event(vq->last_used_event, new + vq->num, new)
> > would suffice.
> > 
> > Am I missing something, or is this irrelevant?

Could you pls repost the suggestion copying virtio-dev mailing list
(subscriber only, sorry about that, but host/guest ABI discussions
need to copy that list)?

> Looks not, I think this may work. Let me do some test.
> 
> Thanks

I think that at this point it's prudent to add a feature bit
as the virtio spec does not require to never move the event index back.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web