search for: virtq

Hello Michael, On Tue, Jan 27, 2015 at 6:01 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > Hi Nikolay, > I poked at src/lib/virtio/virtq.lua a bit - > I was surprised to find no explicit CPU memory > barriers in the virtq implementation. > These are typically required when using virtio > on smp machines - the spec actually mention where > barriers are necessary. > Are the barriers implicit somehow for lua? > I...

Hi Nikolay, I poked at src/lib/virtio/virtq.lua a bit - I was surprised to find no explicit CPU memory barriers in the virtq implementation. These are typically required when using virtio on smp machines - the spec actually mention where barriers are necessary. Are the barriers implicit somehow for lua? I'd be curious to learn. Thanks,...

Hi Nikolay, I poked at src/lib/virtio/virtq.lua a bit - I was surprised to find no explicit CPU memory barriers in the virtq implementation. These are typically required when using virtio on smp machines - the spec actually mention where barriers are necessary. Are the barriers implicit somehow for lua? I'd be curious to learn. Thanks,...

Howdy, On 8 April 2015 at 17:15, Xie, Huawei <huawei.xie at intel.com> wrote: > luke: > 1. host read the flag. 2 guest toggles the flag 3.guest checks the used. > 4. host update used. > Is this your case? > Yep, that is exactly the case I mean. Cheers, -Luke -------------- next part -------------- An HTML attachment was scrubbed... URL:

Howdy, On 8 April 2015 at 17:15, Xie, Huawei <huawei.xie at intel.com> wrote: > luke: > 1. host read the flag. 2 guest toggles the flag 3.guest checks the used. > 4. host update used. > Is this your case? > Yep, that is exactly the case I mean. Cheers, -Luke -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Wed, Oct 02, 2019 at 09:40:11AM +0200, Miklos Szeredi wrote: > Looking at the ugly retry logic in virtiofs and have some questions. Hi Miklos, What are you thinking w.r.t cleanup of retry logic. As of now we put requests in a list and retry later with the help of a worker. Other option will probably be block the submitter if queue is full. Make it sleep, wake up after a while and retry

* Miklos Szeredi (miklos at szeredi.hu) wrote: > Looking at the ugly retry logic in virtiofs and have some questions. > First one is, where do these features come from: > > VIRTIO_F_RING_PACKED > VIRTIO_RING_F_INDIRECT_DESC > > I see that in virtiofs "packed" is off and "indirect" is on. Is this > guaranteed? I think the xdindirect is coming from

On 4/7/2015 10:23 PM, Luke Gorrie wrote: > Hi Michael, > > I'm writing to follow up the previous discussion about memory barriers in > virtio-net device implementations, and Cc'ing the DPDK list because I > believe this is relevant to them too. > > First, thanks again for getting in touch and reviewing our code. > > I have now found a missed case where we *do*

On Tue, Apr 07, 2015 at 04:22:42PM +0200, Luke Gorrie wrote: > Hi Michael, > > I'm writing to follow up the previous discussion about memory barriers in > virtio-net device implementations, and Cc'ing the DPDK list because I believe > this is relevant to them too. > > First, thanks again for getting in touch and reviewing our code. > > I have now found a

...you elaborate a bit more that why it is important. Device does not provide any guarantees that requests will be completed in order of submission. If that's the case, then submitter can't assume any order in request completion anyway. > > This is complicated by the fact that we call virtqueue_add_sgs() under > spinlock, which is the reason GFP_ATOMIC is used. However GFP_ATOMIC > can easily fail and that means even if the "indirect_desc" feature is > turned on a request may use several slots of the ring buffer for a > single request. Aha, you are referring to...

...the RDMA/RoCE > > Virtio Specification and a look forward on possible implementation > > techniques. > > > > Open issues/Todo list: > > List is huge, this is only start point of the project. > > Anyway, here is one example of item in the list: > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means that > > in order to support for example 32K QPs we will need 64K VirtQ. Not sure > > that this is reasonable so one option is to have one for all and > > multiplex the traffic on it. This is not good approach as by de...

...the RDMA/RoCE > > Virtio Specification and a look forward on possible implementation > > techniques. > > > > Open issues/Todo list: > > List is huge, this is only start point of the project. > > Anyway, here is one example of item in the list: > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means that > > in order to support for example 32K QPs we will need 64K VirtQ. Not sure > > that this is reasonable so one option is to have one for all and > > multiplex the traffic on it. This is not good approach as by de...

Otherwise the virtqueue object to instate could point to invalid address that was unmapped from the MTT: mlx5_core 0000:41:04.2: mlx5_cmd_out_err:782:(pid 8321): CREATE_GENERAL_OBJECT(0xa00) op_mod(0xd) failed, status bad parameter(0x3), syndrome (0x5fa1c), err(-22) Fixes: cae15c2ed8e6 ("vdpa/mlx5: Implem...

...that our setup on >>>>>>> the virtio-fs device-side (a DPU) does not easily allow multiple cores to >>>>>>> tend to a single virtio queue. >>>>> >>>>> This is an interesting limitation in DPU. >>>> >>>> Virtqueues are single-consumer queues anyway. Sharing them between >>>> multiple threads would be expensive. I think using multiqueue is natural >>>> and not specific to DPUs. >>> >>> Can we create multiple threads (a thread pool) on DPU and let these >>&gt...

On Wed, Feb 15, 2023 at 9:31 AM Si-Wei Liu <si-wei.liu at oracle.com> wrote: > > Otherwise the virtqueue object to instate could point to invalid address > that was unmapped from the MTT: > > mlx5_core 0000:41:04.2: mlx5_cmd_out_err:782:(pid 8321): > CREATE_GENERAL_OBJECT(0xa00) op_mod(0xd) failed, status > bad parameter(0x3), syndrome (0x5fa1c), err(-22) > > Fixes: cae1...

On 2/15/2023 8:48 PM, Jason Wang wrote: > On Wed, Feb 15, 2023 at 9:31 AM Si-Wei Liu <si-wei.liu at oracle.com> wrote: >> Otherwise the virtqueue object to instate could point to invalid address >> that was unmapped from the MTT: >> >> mlx5_core 0000:41:04.2: mlx5_cmd_out_err:782:(pid 8321): >> CREATE_GENERAL_OBJECT(0xa00) op_mod(0xd) failed, status >> bad parameter(0x3), syndrome (0x5fa1c), err(-22...

...ward on possible implementation > > > > techniques. > > > > > > > > Open issues/Todo list: > > > > List is huge, this is only start point of the project. > > > > Anyway, here is one example of item in the list: > > > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means that > > > > in order to support for example 32K QPs we will need 64K VirtQ. Not sure > > > > that this is reasonable so one option is to have one for all and > > > > multiplex the traffic on it. T...

...ward on possible implementation > > > > techniques. > > > > > > > > Open issues/Todo list: > > > > List is huge, this is only start point of the project. > > > > Anyway, here is one example of item in the list: > > > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means that > > > > in order to support for example 32K QPs we will need 64K VirtQ. Not sure > > > > that this is reasonable so one option is to have one for all and > > > > multiplex the traffic on it. T...

...the RDMA/RoCE > > Virtio Specification and a look forward on possible implementation > > techniques. > > > > Open issues/Todo list: > > List is huge, this is only start point of the project. > > Anyway, here is one example of item in the list: > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means that > > in order to support for example 32K QPs we will need 64K VirtQ. Not sure > > that this is reasonable so one option is to have one for all and > > multiplex the traffic on it. This is not good approach as by de...

...the RDMA/RoCE > > Virtio Specification and a look forward on possible implementation > > techniques. > > > > Open issues/Todo list: > > List is huge, this is only start point of the project. > > Anyway, here is one example of item in the list: > > - Multi VirtQ: Every QP has two rings and every CQ has one. This means that > > in order to support for example 32K QPs we will need 64K VirtQ. Not sure > > that this is reasonable so one option is to have one for all and > > multiplex the traffic on it. This is not good approach as by de...