On Thu, Jun 06, 2019 at 08:34:17AM -0400, Michael S. Tsirkin wrote:
> On Tue, Apr 30, 2019 at 06:41:14PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Feb 11, 2019 at 08:52:01AM +, David Riddoch wrote:
> > > > > Presumably we would like this to be an optional feature, as
> > > > > implementatio
On Tue, Apr 30, 2019 at 06:41:14PM -0400, Michael S. Tsirkin wrote:
> On Mon, Feb 11, 2019 at 08:52:01AM +, David Riddoch wrote:
> > > > Presumably we would like this to be an optional feature, as
> > > > implementations
> > > > of packed mode already exist in the wild. How about
> > > > VIRT
On Mon, Feb 11, 2019 at 08:52:01AM +, David Riddoch wrote:
> > > Presumably we would like this to be an optional feature, as
> > > implementations
> > > of packed mode already exist in the wild. How about
> > > VIRTIO_F_RING_PACKED_AVAIL_IDX?
> > > If I prepare a patch to the spec is there st
On Tue, Feb 19, 2019 at 02:33:04PM +0800, Jason Wang wrote:
>
> On 2019/2/14 下午12:04, Michael S. Tsirkin wrote:
> > On Thu, Feb 14, 2019 at 11:34:22AM +0800, Jason Wang wrote:
> > > On 2019/2/14 上午1:30, Michael S. Tsirkin wrote:
> > > > On Wed, Feb 13, 2019 at 06:33:50PM +0800, Jason Wang wrote:
>
On Tue, Feb 19, 2019 at 02:21:01PM +0800, Jason Wang wrote:
>
> On 2019/2/15 下午12:23, Michael S. Tsirkin wrote:
> > On Fri, Feb 15, 2019 at 11:59:55AM +0800, Jason Wang wrote:
> > > On 2019/2/14 上午11:41, Michael S. Tsirkin wrote:
> > > > > I think it's as simple as increase the avail idx by X? Sin
On 2019/2/14 下午12:04, Michael S. Tsirkin wrote:
On Thu, Feb 14, 2019 at 11:34:22AM +0800, Jason Wang wrote:
On 2019/2/14 上午1:30, Michael S. Tsirkin wrote:
On Wed, Feb 13, 2019 at 06:33:50PM +0800, Jason Wang wrote:
On 2019/2/13 上午1:35, Michael S. Tsirkin wrote:
On Tue, Feb 12, 2019 at 04:47
On 2019/2/15 下午12:23, Michael S. Tsirkin wrote:
On Fri, Feb 15, 2019 at 11:59:55AM +0800, Jason Wang wrote:
On 2019/2/14 上午11:41, Michael S. Tsirkin wrote:
I think it's as simple as increase the avail idx by X? Since descriptor were
used in order, device can just read the next X-1 descriptors
On Fri, Feb 15, 2019 at 11:59:55AM +0800, Jason Wang wrote:
>
> On 2019/2/14 上午11:41, Michael S. Tsirkin wrote:
> > > I think it's as simple as increase the avail idx by X? Since descriptor
> > > were
> > > used in order, device can just read the next X-1 descriptors in this case.
> > >
> > > Th
On 2019/2/14 上午11:41, Michael S. Tsirkin wrote:
I think it's as simple as increase the avail idx by X? Since descriptor were
used in order, device can just read the next X-1 descriptors in this case.
Thanks
Right so a spec change would be needed, it's not transparent to guest.
With the cha
On Thu, Feb 14, 2019 at 11:34:22AM +0800, Jason Wang wrote:
>
> On 2019/2/14 上午1:30, Michael S. Tsirkin wrote:
> > On Wed, Feb 13, 2019 at 06:33:50PM +0800, Jason Wang wrote:
> > > On 2019/2/13 上午1:35, Michael S. Tsirkin wrote:
> > > > On Tue, Feb 12, 2019 at 04:47:08PM +, David Riddoch wrote:
On Thu, Feb 14, 2019 at 11:21:54AM +0800, Jason Wang wrote:
>
> On 2019/2/13 下午11:20, Michael S. Tsirkin wrote:
> > On Wed, Feb 13, 2019 at 06:00:41PM +0800, Jason Wang wrote:
> > > On 2019/2/12 下午9:44, Michael S. Tsirkin wrote:
> > > > On Tue, Feb 12, 2019 at 03:28:26PM +0800, Jason Wang wrote:
>
On 2019/2/14 上午1:30, Michael S. Tsirkin wrote:
On Wed, Feb 13, 2019 at 06:33:50PM +0800, Jason Wang wrote:
On 2019/2/13 上午1:35, Michael S. Tsirkin wrote:
On Tue, Feb 12, 2019 at 04:47:08PM +, David Riddoch wrote:
I would prefer to have the write barrier before writing the idx.
Well that
On 2019/2/13 下午11:20, Michael S. Tsirkin wrote:
On Wed, Feb 13, 2019 at 06:00:41PM +0800, Jason Wang wrote:
On 2019/2/12 下午9:44, Michael S. Tsirkin wrote:
On Tue, Feb 12, 2019 at 03:28:26PM +0800, Jason Wang wrote:
On 2019/2/12 下午1:08, Michael S. Tsirkin wrote:
On Mon, Feb 11, 2019 at 02:58
On Tue, Feb 12, 2019 at 03:03:06PM -0500, Rob Miller wrote:
>
>
> On Tue, Feb 12, 2019 at 1:55 PM Michael S. Tsirkin wrote:
>
> On Fri, Feb 01, 2019 at 09:43:02AM -0800, Rob Miller wrote:
> > Agreed that this is needed.
> >
> > I would also like to suggest splitting the F_IN_ORD
On Wed, Feb 13, 2019 at 06:33:50PM +0800, Jason Wang wrote:
>
> On 2019/2/13 上午1:35, Michael S. Tsirkin wrote:
> > On Tue, Feb 12, 2019 at 04:47:08PM +, David Riddoch wrote:
> > > > > > > I would prefer to have the write barrier before writing the idx.
> > > > > > Well that's driver overhead f
On Wed, Feb 13, 2019 at 06:00:41PM +0800, Jason Wang wrote:
>
> On 2019/2/12 下午9:44, Michael S. Tsirkin wrote:
> > On Tue, Feb 12, 2019 at 03:28:26PM +0800, Jason Wang wrote:
> > > On 2019/2/12 下午1:08, Michael S. Tsirkin wrote:
> > > > On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
On 2019/2/13 上午1:35, Michael S. Tsirkin wrote:
On Tue, Feb 12, 2019 at 04:47:08PM +, David Riddoch wrote:
I would prefer to have the write barrier before writing the idx.
Well that's driver overhead for something device might never utilise in
a given workload. If we are optimizing let's o
On 2019/2/12 下午9:44, Michael S. Tsirkin wrote:
On Tue, Feb 12, 2019 at 03:28:26PM +0800, Jason Wang wrote:
On 2019/2/12 下午1:08, Michael S. Tsirkin wrote:
On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
This can result in a very high rate of doorbells with some
drivers, which c
Maybe we should use a flag in event suppression structure.
This way device can switch between being notification driven
and being driven by index reads.
On first thought it seems hard to avoid races: On receiving a doorbell the
device wishes to transition from doorbells to polling, so driver->
On Tue, Feb 12, 2019 at 1:55 PM Michael S. Tsirkin wrote:
> On Fri, Feb 01, 2019 at 09:43:02AM -0800, Rob Miller wrote:
> > Agreed that this is needed.
> >
> > I would also like to suggest splitting the F_IN_ORDER into
> > F_RX_IN_ORDER and F_TX_IN_ORDER to support hw LRO implementations,
> > whi
On Mon, Feb 04, 2019 at 01:36:28PM +0800, Stefan Hajnoczi wrote:
> On Fri, Feb 01, 2019 at 09:43:02AM -0800, Rob Miller wrote:
> > Agreed that this is needed.
> >
> > I would also like to suggest splitting the F_IN_ORDER into
> > F_RX_IN_ORDER and F_TX_IN_ORDER to support hw LRO implementations,
>
On Fri, Feb 01, 2019 at 09:43:02AM -0800, Rob Miller wrote:
> Agreed that this is needed.
>
> I would also like to suggest splitting the F_IN_ORDER into
> F_RX_IN_ORDER and F_TX_IN_ORDER to support hw LRO implementations,
> which can be more of a scatter/gather than tx. This would allow
> batchmod
On Tue, Feb 12, 2019 at 04:47:08PM +, David Riddoch wrote:
>
> > > > > I would prefer to have the write barrier before writing the idx.
> > > > Well that's driver overhead for something device might never utilise in
> > > > a given workload. If we are optimizing let's optimize for speed.
> > >
I would prefer to have the write barrier before writing the idx.
Well that's driver overhead for something device might never utilise in
a given workload. If we are optimizing let's optimize for speed.
I think doing the barrier before writing idx is best for speed (see below).
I don't see it
On Tue, Feb 12, 2019 at 11:40:25AM +, David Riddoch wrote:
> On 12/02/2019 05:08, Michael S. Tsirkin wrote:
> > On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
> > > > > > > This can result in a very high rate of doorbells with some
> > > > > > > drivers, which can become a sever
On Tue, Feb 12, 2019 at 03:28:26PM +0800, Jason Wang wrote:
>
> On 2019/2/12 下午1:08, Michael S. Tsirkin wrote:
> > On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
> > > > > > > This can result in a very high rate of doorbells with some
> > > > > > > drivers, which can become a sever
On Tue, Feb 12, 2019 at 11:40:25AM +, David Riddoch wrote:
> On 12/02/2019 05:08, Michael S. Tsirkin wrote:
> > On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
> > > > > > > This can result in a very high rate of doorbells with some
> > > > > > > drivers, which can become a sever
On 12/02/2019 05:08, Michael S. Tsirkin wrote:
On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
This can result in a very high rate of doorbells with some
drivers, which can become a severe bottleneck (because x86 CPUs can't emit
MMIOs at very high rates).
Interesting. Is there an
On 2019/2/12 下午1:08, Michael S. Tsirkin wrote:
On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
This can result in a very high rate of doorbells with some
drivers, which can become a severe bottleneck (because x86 CPUs can't emit
MMIOs at very high rates).
Interesting. Is there
On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
> > > > > This can result in a very high rate of doorbells with some
> > > > > drivers, which can become a severe bottleneck (because x86 CPUs can't
> > > > > emit
> > > > > MMIOs at very high rates).
> > > > Interesting. Is there any
This can result in a very high rate of doorbells with some
drivers, which can become a severe bottleneck (because x86 CPUs can't emit
MMIOs at very high rates).
Interesting. Is there any data you could share to help guide the design?
E.g. what's the highest rate of MMIO writes supported etc?
On
On Mon, Feb 11, 2019 at 08:52:01AM +, David Riddoch wrote:
> On 11/02/2019 07:33, Michael S. Tsirkin wrote:
> > On Fri, Feb 01, 2019 at 02:23:55PM +, David Riddoch wrote:
> > > All,
> > >
> > > I'd like to propose a small extension to the packed virtqueue mode. My
> > > proposal is to add
On 11/02/2019 07:33, Michael S. Tsirkin wrote:
On Fri, Feb 01, 2019 at 02:23:55PM +, David Riddoch wrote:
All,
I'd like to propose a small extension to the packed virtqueue mode. My
proposal is to add an offset/wrap field, written by the driver, indicating
how many available descriptors ha
On Fri, Feb 01, 2019 at 02:23:55PM +, David Riddoch wrote:
> All,
>
> I'd like to propose a small extension to the packed virtqueue mode. My
> proposal is to add an offset/wrap field, written by the driver, indicating
> how many available descriptors have been added to the ring.
>
> The reas
On Fri, Feb 01, 2019 at 09:43:02AM -0800, Rob Miller wrote:
> Agreed that this is needed.
>
> I would also like to suggest splitting the F_IN_ORDER into
> F_RX_IN_ORDER and F_TX_IN_ORDER to support hw LRO implementations,
> which can be more of a scatter/gather than tx. This would allow
> batchmod
Agreed that this is needed.
I would also like to suggest splitting the F_IN_ORDER into
F_RX_IN_ORDER and F_TX_IN_ORDER to support hw LRO implementations,
which can be more of a scatter/gather than tx. This would allow
batchmode for tx at least in packed rings.
Finally, i would suggest a means to
All,
I'd like to propose a small extension to the packed virtqueue mode. My
proposal is to add an offset/wrap field, written by the driver,
indicating how many available descriptors have been added to the ring.
The reason for wanting this is to improve performance of hardware
devices. Beca
37 matches
Mail list logo
