On 4/7/21 10:26 AM, Thomas Monjalon wrote:
> 07/04/2021 09:47, Maxime Coquelin:
>>
>> On 3/17/21 6:40 AM, Cheng Jiang wrote:
>>> We use ioat ring space for determining if ioat callbacks can enqueue a
>>> packet to ioat device. But there is one slot can't be used in ioat
>>> ring due to the ioat driver design, so we need to reduce one slot in
>>> ioat ring to prevent ring size mismatch in ioat callbacks.
>>>
>>> Fixes: 2aa47e94bfb2 ("examples/vhost: add ioat ring space count and check")
>>> Cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Cheng Jiang <cheng1.ji...@intel.com>
>>> ---
>>> examples/vhost/ioat.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/examples/vhost/ioat.c b/examples/vhost/ioat.c
>>> index 60b73be93..9cb5e0d50 100644
>>> --- a/examples/vhost/ioat.c
>>> +++ b/examples/vhost/ioat.c
>>> @@ -113,7 +113,7 @@ open_ioat(const char *value)
>>> goto out;
>>> }
>>> rte_rawdev_start(dev_id);
>>> - cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE;
>>> + cb_tracker[dev_id].ioat_space = IOAT_RING_SIZE - 1;
>>
>> That really comforts me in thinking we need a generic abstraction for
>> DMA devices. How is the application developer supposed to know that
>> the DMA driver has such weird limitations?
>
> Having a generic DMA API may be interesting.
> Do you know any other HW candidate for such an API?
> Do you think rte_memcpy can be used as a SW driver?
Yes, I guess we could create a vdev driver with MEM_TO_MEM capability
using rte_memcpy().
Note that IOAT in the Kernel is supported by the DMA framework.
Regards,
Maxime
