DPDK patches and discussions
 help / color / mirror / Atom feed
* [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).