* [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).