search for: out_of_ord

On Thu, Oct 11, 2018 at 08:12:21PM +0800, Tiwei Bie wrote: > > > But if it's not too late, I second for a OUT_OF_ORDER feature. > > > Starting from in order can have much simpler code in driver. > > > > > > Thanks > > > > It's tricky to change the flag polarity because of compatibility > > with legacy interfaces. Why is this such a big deal? > > > >...

...ewhere even for in order > device. For a bunch of systems dma unmap is a nop so we do not really need to maintain it. It's a question of an API to detect that and optimize for it. I posted a proposed patch for that - want to try using that? > But if it's not too late, I second for a OUT_OF_ORDER feature. > Starting from in order can have much simpler code in driver. > > Thanks It's tricky to change the flag polarity because of compatibility with legacy interfaces. Why is this such a big deal? Let's teach drivers about IN_ORDER, then if devices are in order it will get...

On Thu, Oct 11, 2018 at 10:13:31PM +0800, Tiwei Bie wrote: > On Thu, Oct 11, 2018 at 09:48:48AM -0400, Michael S. Tsirkin wrote: > > On Thu, Oct 11, 2018 at 08:12:21PM +0800, Tiwei Bie wrote: > > > > > But if it's not too late, I second for a OUT_OF_ORDER feature. > > > > > Starting from in order can have much simpler code in driver. > > > > > > > > > > Thanks > > > > > > > > It's tricky to change the flag polarity because of compatibility > > > > with legacy in...

...> If it is true, I'll do it. So do you think we also want > to maintain such a desc/ctx list for packed ring? To make it work for OOO backends I think we need something like this (hardware NIC drivers are usually have something like this). Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is much more simpler to be started with. Thanks > > Best regards, > Tiwei Bie

...> If it is true, I'll do it. So do you think we also want > to maintain such a desc/ctx list for packed ring? To make it work for OOO backends I think we need something like this (hardware NIC drivers are usually have something like this). Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is much more simpler to be started with. Thanks > > Best regards, > Tiwei Bie

...ardware NIC drivers are usually have something like this). > Which hardware NIC drivers have this? It's quite common I think, e.g driver track e.g dma addr and page frag somewhere. e.g the ring->rx_info in mlx4 driver. Thanks > >> Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is >> much more simpler to be started with. > +1 > > Best regards, > Tiwei Bie

...ardware NIC drivers are usually have something like this). > Which hardware NIC drivers have this? It's quite common I think, e.g driver track e.g dma addr and page frag somewhere. e.g the ring->rx_info in mlx4 driver. Thanks > >> Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is >> much more simpler to be started with. > +1 > > Best regards, > Tiwei Bie

...he next batch, etc. " So: - It's an alignment to the spec - device may (or should) overwrite the descriptor make also make address field useless. Thanks > > Best regards, > Tiwei Bie > >> Thanks >> >>>> Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is >>>> much more simpler to be started with. >>> +1 >>> >>> Best regards, >>> Tiwei Bie

...he next batch, etc. " So: - It's an alignment to the spec - device may (or should) overwrite the descriptor make also make address field useless. Thanks > > Best regards, > Tiwei Bie > >> Thanks >> >>>> Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is >>>> much more simpler to be started with. >>> +1 >>> >>> Best regards, >>> Tiwei Bie

...; > to maintain such a desc/ctx list for packed ring? > > To make it work for OOO backends I think we need something like this > (hardware NIC drivers are usually have something like this). Which hardware NIC drivers have this? > > Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is > much more simpler to be started with. +1 Best regards, Tiwei Bie

...tor table in the split ring (the > difference is that, it only happens in driver now). Out of order is not the only user, DMA is another one. We don't have used ring(len), so we need to maintain buffer length somewhere even for in order device. But if it's not too late, I second for a OUT_OF_ORDER feature. Starting from in order can have much simpler code in driver. Thanks

...bunch of systems dma unmap is a nop so we do not really > need to maintain it. It's a question of an API to detect that > and optimize for it. I posted a proposed patch for that - > want to try using that? Yeah, definitely! > > > But if it's not too late, I second for a OUT_OF_ORDER feature. > > Starting from in order can have much simpler code in driver. > > > > Thanks > > It's tricky to change the flag polarity because of compatibility > with legacy interfaces. Why is this such a big deal? > > Let's teach drivers about IN_ORDER,...

On Thu, Oct 11, 2018 at 09:48:48AM -0400, Michael S. Tsirkin wrote: > On Thu, Oct 11, 2018 at 08:12:21PM +0800, Tiwei Bie wrote: > > > > But if it's not too late, I second for a OUT_OF_ORDER feature. > > > > Starting from in order can have much simpler code in driver. > > > > > > > > Thanks > > > > > > It's tricky to change the flag polarity because of compatibility > > > with legacy interfaces. Why is this such a b...

On Wed, Sep 12, 2018 at 12:16:32PM -0400, Michael S. Tsirkin wrote: > On Tue, Sep 11, 2018 at 01:37:26PM +0800, Tiwei Bie wrote: > > On Mon, Sep 10, 2018 at 11:33:17AM +0800, Jason Wang wrote: > > > On 2018?09?10? 11:00, Tiwei Bie wrote: > > > > On Fri, Sep 07, 2018 at 09:00:49AM -0400, Michael S. Tsirkin wrote: > > > > > On Fri, Sep 07, 2018 at

...index, priv->cqe_size) + factor; ``` It seems that although they have a completion queue, they are still using the ring in order. I guess maybe storage device may want OOO. Best regards, Tiwei Bie > > Thanks > > > > > > Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is > > > much more simpler to be started with. > > +1 > > > > Best regards, > > Tiwei Bie >

...hich is a little bit sad). Maybe Michael had. Thanks > > Best regards, > Tiwei Bie > >> Thanks >> >>> Best regards, >>> Tiwei Bie >>> >>>> Thanks >>>> >>>>>> Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is >>>>>> much more simpler to be started with. >>>>> +1 >>>>> >>>>> Best regards, >>>>> Tiwei Bie

...hich is a little bit sad). Maybe Michael had. Thanks > > Best regards, > Tiwei Bie > >> Thanks >> >>> Best regards, >>> Tiwei Bie >>> >>>> Thanks >>>> >>>>>> Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is >>>>>> much more simpler to be started with. >>>>> +1 >>>>> >>>>> Best regards, >>>>> Tiwei Bie

...mean I don't want to support OOO. It's just a simple question...) Best regards, Tiwei Bie > > Thanks > > > > > Best regards, > > Tiwei Bie > > > > > Thanks > > > > > > > > Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is > > > > > much more simpler to be started with. > > > > +1 > > > > > > > > Best regards, > > > > Tiwei Bie >

On 2018?05?16? 20:39, Tiwei Bie wrote: > On Wed, May 16, 2018 at 07:50:16PM +0800, Jason Wang wrote: >> On 2018?05?16? 16:37, Tiwei Bie wrote: > [...] >>> struct vring_virtqueue { >>> @@ -116,6 +117,9 @@ struct vring_virtqueue { >>> /* Last written value to driver->flags in >>> * guest byte order. */ >>> u16

On 2018?05?16? 20:39, Tiwei Bie wrote: > On Wed, May 16, 2018 at 07:50:16PM +0800, Jason Wang wrote: >> On 2018?05?16? 16:37, Tiwei Bie wrote: > [...] >>> struct vring_virtqueue { >>> @@ -116,6 +117,9 @@ struct vring_virtqueue { >>> /* Last written value to driver->flags in >>> * guest byte order. */ >>> u16