* [dpdk-dev] rte_vfio_container_dma_map/unmap functions
@ 2020-03-22 17:20 Tal Shnaiderman
2020-04-17 14:05 ` Burakov, Anatoly
0 siblings, 1 reply; 8+ messages in thread
From: Tal Shnaiderman @ 2020-03-22 17:20 UTC (permalink / raw)
To: anatoly.burakov; +Cc: Thomas Monjalon, dev
Hi Anatoly,
I'm working on the implementation of bus/pci driver for Windows, pci_common.c uses the titled functions however they are relevant only for Linux OS.
I'm wondering if the implementation of those functions should be moved to a Linux specific area since FreeBSD (and now Windows) are forced to implemented those in the current state.
Would appreciate your feedback,
Regards,
Tal
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] rte_vfio_container_dma_map/unmap functions
2020-03-22 17:20 [dpdk-dev] rte_vfio_container_dma_map/unmap functions Tal Shnaiderman
@ 2020-04-17 14:05 ` Burakov, Anatoly
2020-04-17 14:09 ` Burakov, Anatoly
0 siblings, 1 reply; 8+ messages in thread
From: Burakov, Anatoly @ 2020-04-17 14:05 UTC (permalink / raw)
To: Tal Shnaiderman; +Cc: Thomas Monjalon, dev
On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
> Hi Anatoly,
>
> I’m working on the implementation of bus/pci driver for Windows,
> pci_common.c uses the titled functions however they are relevant only
> for Linux OS.
>
> I’m wondering if the implementation of those functions should be moved
> to a Linux specific area since FreeBSD (and now Windows) are forced to
> implemented those in the current state.
>
> Would appreciate your feedback,
>
> Regards,
>
> Tal
>
Hi,
I believe those functions are marked as deprecated now. We probably
could remove them in 20.11?
--
Thanks,
Anatoly
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] rte_vfio_container_dma_map/unmap functions
2020-04-17 14:05 ` Burakov, Anatoly
@ 2020-04-17 14:09 ` Burakov, Anatoly
2020-04-19 13:09 ` Thomas Monjalon
0 siblings, 1 reply; 8+ messages in thread
From: Burakov, Anatoly @ 2020-04-17 14:09 UTC (permalink / raw)
To: Tal Shnaiderman; +Cc: Thomas Monjalon, dev
On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
> On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
>> Hi Anatoly,
>>
>> I’m working on the implementation of bus/pci driver for Windows,
>> pci_common.c uses the titled functions however they are relevant only
>> for Linux OS.
>>
>> I’m wondering if the implementation of those functions should be moved
>> to a Linux specific area since FreeBSD (and now Windows) are forced to
>> implemented those in the current state.
>>
>> Would appreciate your feedback,
>>
>> Regards,
>>
>> Tal
>>
>
> Hi,
>
> I believe those functions are marked as deprecated now. We probably
> could remove them in 20.11?
>
Sorry, was thinking of different functions (not the container related ones).
Unfortunately, we don't have a generic API for these, but since we
export a single API on all platforms, either all platforms have to
implement these functions, or none of them do. There's simply no way to
avoid implementing stubs for these functions, short of coming up with a
generic API that would replace these. Given that this API is heavily
Linux specific, i don't see that happening.
--
Thanks,
Anatoly
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] rte_vfio_container_dma_map/unmap functions
2020-04-17 14:09 ` Burakov, Anatoly
@ 2020-04-19 13:09 ` Thomas Monjalon
2020-04-19 13:10 ` Thomas Monjalon
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2020-04-19 13:09 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: Tal Shnaiderman, dev, dev
17/04/2020 16:09, Burakov, Anatoly:
> On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
> > On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
> >> Hi Anatoly,
> >>
> >> I’m working on the implementation of bus/pci driver for Windows,
> >> pci_common.c uses the titled functions however they are relevant only
> >> for Linux OS.
> >>
> >> I’m wondering if the implementation of those functions should be moved
> >> to a Linux specific area since FreeBSD (and now Windows) are forced to
> >> implemented those in the current state.
>
> Unfortunately, we don't have a generic API for these, but since we
> export a single API on all platforms, either all platforms have to
> implement these functions, or none of them do. There's simply no way to
> avoid implementing stubs for these functions, short of coming up with a
> generic API that would replace these. Given that this API is heavily
> Linux specific, i don't see that happening.
Because it is Linux specific, we should not force FreeBSD and Windows
having stubs. Can we move VFIO calls in Linux-specific files?
I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] rte_vfio_container_dma_map/unmap functions
2020-04-19 13:09 ` Thomas Monjalon
@ 2020-04-19 13:10 ` Thomas Monjalon
2020-04-20 14:07 ` Burakov, Anatoly
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2020-04-19 13:10 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: dev, Tal Shnaiderman, bruce.richardson, david.marchand
19/04/2020 15:09, Thomas Monjalon:
> 17/04/2020 16:09, Burakov, Anatoly:
> > On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
> > > On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
> > >> Hi Anatoly,
> > >>
> > >> I’m working on the implementation of bus/pci driver for Windows,
> > >> pci_common.c uses the titled functions however they are relevant only
> > >> for Linux OS.
> > >>
> > >> I’m wondering if the implementation of those functions should be moved
> > >> to a Linux specific area since FreeBSD (and now Windows) are forced to
> > >> implemented those in the current state.
> >
> > Unfortunately, we don't have a generic API for these, but since we
> > export a single API on all platforms, either all platforms have to
> > implement these functions, or none of them do. There's simply no way to
> > avoid implementing stubs for these functions, short of coming up with a
> > generic API that would replace these. Given that this API is heavily
> > Linux specific, i don't see that happening.
>
> Because it is Linux specific, we should not force FreeBSD and Windows
> having stubs. Can we move VFIO calls in Linux-specific files?
>
> I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
+Cc Bruce and David
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] rte_vfio_container_dma_map/unmap functions
2020-04-19 13:10 ` Thomas Monjalon
@ 2020-04-20 14:07 ` Burakov, Anatoly
2020-04-20 17:39 ` Thomas Monjalon
0 siblings, 1 reply; 8+ messages in thread
From: Burakov, Anatoly @ 2020-04-20 14:07 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Tal Shnaiderman, bruce.richardson, david.marchand
On 19-Apr-20 2:10 PM, Thomas Monjalon wrote:
> 19/04/2020 15:09, Thomas Monjalon:
>> 17/04/2020 16:09, Burakov, Anatoly:
>>> On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
>>>> On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
>>>>> Hi Anatoly,
>>>>>
>>>>> I’m working on the implementation of bus/pci driver for Windows,
>>>>> pci_common.c uses the titled functions however they are relevant only
>>>>> for Linux OS.
>>>>>
>>>>> I’m wondering if the implementation of those functions should be moved
>>>>> to a Linux specific area since FreeBSD (and now Windows) are forced to
>>>>> implemented those in the current state.
>>>
>>> Unfortunately, we don't have a generic API for these, but since we
>>> export a single API on all platforms, either all platforms have to
>>> implement these functions, or none of them do. There's simply no way to
>>> avoid implementing stubs for these functions, short of coming up with a
>>> generic API that would replace these. Given that this API is heavily
>>> Linux specific, i don't see that happening.
>>
>> Because it is Linux specific, we should not force FreeBSD and Windows
>> having stubs. Can we move VFIO calls in Linux-specific files?
>>
>> I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
>
> +Cc Bruce and David
>
>
...and have a Linux-specific ABI?
--
Thanks,
Anatoly
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] rte_vfio_container_dma_map/unmap functions
2020-04-20 14:07 ` Burakov, Anatoly
@ 2020-04-20 17:39 ` Thomas Monjalon
2020-04-21 9:50 ` Burakov, Anatoly
0 siblings, 1 reply; 8+ messages in thread
From: Thomas Monjalon @ 2020-04-20 17:39 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: dev, Tal Shnaiderman, bruce.richardson, david.marchand
20/04/2020 16:07, Burakov, Anatoly:
> On 19-Apr-20 2:10 PM, Thomas Monjalon wrote:
> > 19/04/2020 15:09, Thomas Monjalon:
> >> 17/04/2020 16:09, Burakov, Anatoly:
> >>> On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
> >>>> On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
> >>>>> Hi Anatoly,
> >>>>>
> >>>>> I’m working on the implementation of bus/pci driver for Windows,
> >>>>> pci_common.c uses the titled functions however they are relevant only
> >>>>> for Linux OS.
> >>>>>
> >>>>> I’m wondering if the implementation of those functions should be moved
> >>>>> to a Linux specific area since FreeBSD (and now Windows) are forced to
> >>>>> implemented those in the current state.
> >>>
> >>> Unfortunately, we don't have a generic API for these, but since we
> >>> export a single API on all platforms, either all platforms have to
> >>> implement these functions, or none of them do. There's simply no way to
> >>> avoid implementing stubs for these functions, short of coming up with a
> >>> generic API that would replace these. Given that this API is heavily
> >>> Linux specific, i don't see that happening.
> >>
> >> Because it is Linux specific, we should not force FreeBSD and Windows
> >> having stubs. Can we move VFIO calls in Linux-specific files?
> >>
> >> I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
> >
> > +Cc Bruce and David
>
> ...and have a Linux-specific ABI?
Yes, the ABI is different depending on arch and OS.
That's a fact, and I don't see any problem with it.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dpdk-dev] rte_vfio_container_dma_map/unmap functions
2020-04-20 17:39 ` Thomas Monjalon
@ 2020-04-21 9:50 ` Burakov, Anatoly
0 siblings, 0 replies; 8+ messages in thread
From: Burakov, Anatoly @ 2020-04-21 9:50 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Tal Shnaiderman, bruce.richardson, david.marchand
On 20-Apr-20 6:39 PM, Thomas Monjalon wrote:
> 20/04/2020 16:07, Burakov, Anatoly:
>> On 19-Apr-20 2:10 PM, Thomas Monjalon wrote:
>>> 19/04/2020 15:09, Thomas Monjalon:
>>>> 17/04/2020 16:09, Burakov, Anatoly:
>>>>> On 17-Apr-20 3:05 PM, Burakov, Anatoly wrote:
>>>>>> On 22-Mar-20 5:20 PM, Tal Shnaiderman wrote:
>>>>>>> Hi Anatoly,
>>>>>>>
>>>>>>> I’m working on the implementation of bus/pci driver for Windows,
>>>>>>> pci_common.c uses the titled functions however they are relevant only
>>>>>>> for Linux OS.
>>>>>>>
>>>>>>> I’m wondering if the implementation of those functions should be moved
>>>>>>> to a Linux specific area since FreeBSD (and now Windows) are forced to
>>>>>>> implemented those in the current state.
>>>>>
>>>>> Unfortunately, we don't have a generic API for these, but since we
>>>>> export a single API on all platforms, either all platforms have to
>>>>> implement these functions, or none of them do. There's simply no way to
>>>>> avoid implementing stubs for these functions, short of coming up with a
>>>>> generic API that would replace these. Given that this API is heavily
>>>>> Linux specific, i don't see that happening.
>>>>
>>>> Because it is Linux specific, we should not force FreeBSD and Windows
>>>> having stubs. Can we move VFIO calls in Linux-specific files?
>>>>
>>>> I think rte_vfio.h should be moved in lib/librte_eal/linux/include.
>>>
>>> +Cc Bruce and David
>>
>> ...and have a Linux-specific ABI?
>
> Yes, the ABI is different depending on arch and OS.
> That's a fact, and I don't see any problem with it.
>
OK, no objections then :)
--
Thanks,
Anatoly
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-04-21 9:50 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-22 17:20 [dpdk-dev] rte_vfio_container_dma_map/unmap functions Tal Shnaiderman
2020-04-17 14:05 ` Burakov, Anatoly
2020-04-17 14:09 ` Burakov, Anatoly
2020-04-19 13:09 ` Thomas Monjalon
2020-04-19 13:10 ` Thomas Monjalon
2020-04-20 14:07 ` Burakov, Anatoly
2020-04-20 17:39 ` Thomas Monjalon
2020-04-21 9:50 ` Burakov, Anatoly
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).