[dpdk-dev] [PATCH v2 1/8] eal: define container_of macro
On Tue, 22 Nov 2016 11:26:50 + Shreyansh Jain wrote: > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Tuesday, November 22, 2016 3:50 PM > > To: Shreyansh Jain ; Jan Blunck > > > > Cc: dev at dpdk.org; david.marchand at 6wind.com; Jan Viktorin > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/8] eal: define container_of macro > > > > 2016-11-22 15:33, Shreyansh Jain: > > > On Monday 21 November 2016 10:25 PM, Jan Blunck wrote: > > > > This macro is based on Jan Viktorin's original patch but also checks the > > > > type of the passed pointer against the type of the member. > > > > > > > > Signed-off-by: Jan Viktorin > > > > Signed-off-by: Shreyansh Jain > > > > [jblunck at infradead.org: add type checking and __extension__] > > > > Signed-off-by: Jan Blunck > > > > > > I will start using this in my patchset. > > > > > > Acked-by: Shreyansh Jain > > > > It is a bit strange to have this patch in a series which do > > not use it. I am in favor of getting it when it is used > > (and included) in another series. > > I can add this patch to my series, if Jan is ok about this. It's OK. Just merge it someday ;). Jan > > - > Shreyansh -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v2 1/2] arch/arm: fix file descriptor leakage when getting CPU features
On Fri, 4 Nov 2016 15:16:42 +0530 Jianbo Liu wrote: > close the file descriptor after finish using it. s/close/Close/ > > Fixes: b94e5c94 (eal/arm: add CPU flags for ARMv7) > Fixes: 97523f82 (eal/arm: add CPU flags for ARMv8) > > Signed-off-by: Jianbo Liu Acked-by: Jan Viktorin
[dpdk-dev] [PATCH v2 2/2] arch/ppc: fix file descriptor leakage when getting CPU features
On Fri, 4 Nov 2016 15:16:43 +0530 Jianbo Liu wrote: > close the file descriptor after finish using it. s/close/Close/ Please include my ack (below). Jan > > Fixes: 9ae15538 (eal/ppc: cpu flag checks for IBM Power) > > Signed-off-by: Jianbo Liu Acked-by: Jan Viktorin
[dpdk-dev] [PATCH v5 06/21] eal/soc: introduce very essential SoC infra definitions
On Mon, 24 Oct 2016 17:29:25 +0530
Shreyansh Jain wrote:
> From: Jan Viktorin
>
> Define initial structures and functions for the SoC infrastructure.
> This patch supports only a very minimal functions for now.
> More features will be added in the following commits.
>
> Includes rte_device/rte_driver inheritance of
> rte_soc_device/rte_soc_driver.
>
> Signed-off-by: Jan Viktorin
> Signed-off-by: Shreyansh Jain
> Signed-off-by: Hemant Agrawal
> ---
> app/test/Makefile | 1 +
> app/test/test_soc.c | 90 +
> lib/librte_eal/common/Makefile | 2 +-
> lib/librte_eal/common/eal_private.h | 4 +
> lib/librte_eal/common/include/rte_soc.h | 138
>
> 5 files changed, 234 insertions(+), 1 deletion(-)
> create mode 100644 app/test/test_soc.c
> create mode 100644 lib/librte_eal/common/include/rte_soc.h
>
> diff --git a/app/test/Makefile b/app/test/Makefile
[...]
> +++ b/lib/librte_eal/common/include/rte_soc.h
> @@ -0,0 +1,138 @@
[...]
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +struct rte_soc_id {
> + const char *compatible; /**< OF compatible specification */
> + uint64_t priv_data; /**< SoC Driver specific data */
Do you expect this to be a pointer?
> +};
> +
[...]
> +
> +/**
> + * Initialization function for the driver called during SoC probing.
> + */
> +typedef int (soc_devinit_t)(struct rte_soc_driver *, struct rte_soc_device
> *);
> +
> +/**
> + * Uninitialization function for the driver called during hotplugging.
> + */
> +typedef int (soc_devuninit_t)(struct rte_soc_device *);
> +
> +/**
> + * A structure describing a SoC driver.
> + */
> +struct rte_soc_driver {
> + TAILQ_ENTRY(rte_soc_driver) next; /**< Next in list */
> + struct rte_driver driver; /**< Inherit core driver. */
> + soc_devinit_t *devinit;/**< Device initialization */
> + soc_devuninit_t *devuninit;/**< Device uninitialization */
Shouldn't those functions be named probe/remove?
> + const struct rte_soc_id *id_table; /**< ID table, NULL terminated */
> +};
> +
[...]
> +#endif
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v5 01/21] eal: generalize PCI kernel driver enum to EAL
On Mon, 24 Oct 2016 17:29:20 +0530 Shreyansh Jain wrote: > From: Jan Viktorin > > Signed-off-by: Jan Viktorin > Signed-off-by: Shreyansh Jain I think, there is no reason to prevent merging this. Feel free to add: Acked-by: Jan Viktorin
[dpdk-dev] [PATCH v4 11/17] eal/soc: add default scan for Soc devices
On Mon, 24 Oct 2016 17:38:29 +0530
Shreyansh Jain wrote:
> Hi Jan,
>
> On Sunday 16 October 2016 12:42 PM, Shreyansh Jain wrote:
> > Hi Jan,
> >
[...]
> >>
> >>> +
> >>> +int
> >>> +rte_eal_soc_scan(void)
> >>
> >> What about naming it rte_eal_soc_scan_default? This would underline the
> >> fact that this function can be replaced.
> >
> > Yes, that would be in sync with match default. I will do it.
>
> In v5 I have replaced the name with rte_eal_soc_platform_bus(). This is
> long but it does exactly what the name states - scan for platform bus.
> This is still a helper.
OK.
>
> >
> >>
> >> Second, this is for the 7/17 patch:
> >>
> >> -/* register a driver */
> >> void
> >> rte_eal_soc_register(struct rte_soc_driver *driver)
> >> {
> >> + /* For a valid soc driver, match and scan function
> >> + * should be provided.
> >> + */
> >> + RTE_VERIFY(driver != NULL);
> >> + RTE_VERIFY(driver->match_fn != NULL);
> >> + RTE_VERIFY(driver->scan_fn != NULL);
> >>
> >> What about setting the match_fn and scan_fn to default implementations if
> >> they
> >> are NULL? This would make the standard/default approach easier to use.
> >>
> >>TAILQ_INSERT_TAIL(_driver_list, driver, next);
> >> }
> >
> > I am not in favor of a forced default. What if user never intended it - it
> > would lead to wrong scan being used and only intimation which can provided
> > to user is a log.
> > Selecting such functions should be a model of PMD - one which is enforced.
>
> As mentioned before, I am not in favor of a 'default' implementation.
> Thus, I would rather call these functions as 'helpers' rather than defaults.
Hmm, OK.
Jan
>
> [...]
>
> -
> Shreyansh
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v4 11/17] eal/soc: add default scan for Soc devices
On Sat, 15 Oct 2016 19:15:02 +0530
Shreyansh Jain wrote:
> From: Jan Viktorin
>
> Default implementation which scans the sysfs platform devices hierarchy.
> For each device, extract the ueven and convert into rte_soc_device.
>
> The information populated can then be used in probe to match against
> the drivers registered.
>
> Signed-off-by: Jan Viktorin
> [Shreyansh: restructure commit to be an optional implementation]
> Signed-off-by: Shreyansh Jain
[...]
> +
> +int
> +rte_eal_soc_scan(void)
What about naming it rte_eal_soc_scan_default? This would underline the
fact that this function can be replaced.
Second, this is for the 7/17 patch:
-/* register a driver */
void
rte_eal_soc_register(struct rte_soc_driver *driver)
{
+ /* For a valid soc driver, match and scan function
+* should be provided.
+*/
+ RTE_VERIFY(driver != NULL);
+ RTE_VERIFY(driver->match_fn != NULL);
+ RTE_VERIFY(driver->scan_fn != NULL);
What about setting the match_fn and scan_fn to default implementations if they
are NULL? This would make the standard/default approach easier to use.
TAILQ_INSERT_TAIL(_driver_list, driver, next);
}
> +{
> + struct dirent *e;
> + DIR *dir;
> + char dirname[PATH_MAX];
> +
> + dir = opendir(soc_get_sysfs_path());
> + if (dir == NULL) {
> + RTE_LOG(ERR, EAL, "%s(): opendir failed: %s\n",
> + __func__, strerror(errno));
> + return -1;
> + }
> +
> + while ((e = readdir(dir)) != NULL) {
> + if (e->d_name[0] == '.')
> + continue;
> +
> + snprintf(dirname, sizeof(dirname), "%s/%s",
> + soc_get_sysfs_path(), e->d_name);
> + if (soc_scan_one(dirname, e->d_name) < 0)
> + goto error;
> + }
> + closedir(dir);
> + return 0;
> +
> +error:
> + closedir(dir);
> + return -1;
> +}
> +
> /* Init the SoC EAL subsystem */
> int
> rte_eal_soc_init(void)
--
Jan ViktorinE-mail: Viktorin at RehiveTech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH] doc: arm64: document DPDK application profiling methods
On Tue, 04 Oct 2016 14:40:47 +0200 Thomas Monjalon wrote: > Thanks for providing a patch so quickly :) > > 2016-10-04 16:10, Jerin Jacob: > > +The PMU based scheme useful for high accuracy performance profiling. > > A verb is missing. > > > +Find below the example steps to configure the PMU based cycle counter on an > > +armv8 machine. > > + > > +.. code-block:: console > > + > > +git clone https://github.com/jerinjacobk/armv8_pmu_cycle_counter_el0 > > +cd armv8_pmu_cycle_counter_el0 > > +make > > +sudo insmod pmu_el0_cycle_counter.ko > > +cd $DPDK_DIR > > +make config T=arm64-armv8a-linuxapp-gcc > > +echo "CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU=y" >> build/.config > > +make > > What about the ARM 32 code that Jan is using? Hi, I didn't have time for this yet. The basic description is here: lib/librte_eal/common/include/arch/arm/rte_cycles_32.h In the Linux Kernel, it is used here: arch/arm/kernel/perf_event_v7.c (see registers c12, c13 and c14) Regards Jan > > > +.. warning:: > > + > > +This method can not be used in production systems as this may alter PMU > > +state used by standard Linux user space tool like perf. > > More details please? > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v1 0/4] Generalize PCI specific EAL function/structures
On Mon, 3 Oct 2016 11:07:43 +0530 Shreyansh Jain wrote: > Hi David, > > On Friday 30 September 2016 09:01 PM, David Marchand wrote: > > On Tue, Sep 27, 2016 at 4:12 PM, Shreyansh Jain > > wrote: > >> (I rebased these over HEAD 7b3c4f3) > >> > >> These patches were initially part of Jan's original series on SoC > >> Framework ([1],[2]). An update to that series, without these patches, > >> was posted here [3]. > >> > >> Main motivation for these is aim of introducing a non-PCI centric > >> subsystem in EAL. As of now the first usecase is SoC, but not limited to > >> it. > >> > >> 4 patches in this series are independent of each other, as well as SoC > >> framework. All these focus on generalizing some structure or functions > >> present with the PCI specific code to EAL Common area (or splitting a > >> function to be more userful). > > > > Those patches move linux specifics (binding pci devices using sysfs) > > to common infrastucture. > > We have no proper hotplug support on bsd, but if we had some common > > code we should at least try to make the apis generic. > > > > I am not sure if I understood your point well. Just to confirm - you are I don't clearly see the point, either. Jan > stating that the movement done in the patches might not suit BSD. > Probably you are talking about (Patch 3/4 and 4/4). > Is my understanding correct? > > So, movement to just Linux area is not enough? > I am not well versed with BSD way of doing something similar so if > someone can point it out, I can integrate that. (I will investigate it > at my end as well). > > This patchset makes the PCI->EAL movement *only* for Linux for sysfs > bind/unbind. (I should add this to cover letter, at the least). > > - > Shreyansh -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 09:41:55 + Hemant Agrawal wrote: > > -Original Message- > > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > [...] > > > And for each platform/product > > > > > > > I agree, that this can sometimes lead to code duplication. Moreover, > > > > it opens door for a very non-standard, unsecure and wrong-by-design > > > > approaches. I'd like more to provide one or more scan > > > > implementations in EAL and do not put this responsibility on PMDs. > Hi Hemant. > [Hemant] A common/default scan function can be added, provided at least one > or more PMD driver support it. > w.r.t Jan's original scan function, it was not suitable for any of the NXP > SoC's whether ARM or PowerPC. > > Unable to validate the Jan's scan function on a real platform, we have > skipped it for next phase. > Addition of a default scan function can only be done in next phase, when we > find a suitable SoC PMD driver supporting it. Quite frankly, the situation is same for me. I still have no clue about your approach which seems to be pretty non-standard. I have no way how to test it. My approach can be tested on any Linux machine with platform devices and device-tree enabled. You would see that I detect those devices (I don't mean any certain network device, I mean all platform devices) and if you provide a driver with a proper compatible string it will be set for you. I presume that I don't have any upstreamable PMD for this at the moment.
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 16:56:54 +0800 Jianbo Liu wrote: > On 18 September 2016 at 15:22, Jan Viktorin > wrote: > > On Sun, 18 Sep 2016 13:58:50 +0800 > > Jianbo Liu wrote: > > > >> On 9 September 2016 at 16:43, Shreyansh Jain > >> wrote: > >> > Introduction: > >> > = > >> > > >> > This patch set is direct derivative of Jan's original series [1],[2]. > >> > > >> > - As this deviates substantially from original series, if need be I can > >> >post it as a separate patch rather than v2. Please suggest. > >> > - Also, there are comments on original v1 ([4]) which are _not_ > >> >incorporated in this series as they refer to section no more in new > >> >version. > >> > - This v3 version is based on the rte_driver/device patchset v9 [10]. > >> >That series introduced device structures (rte_driver/rte_device) > >> >generalizing devices into PCI, VDEV, XXX. For the purpose of this > >> >patchset, XXX=>SOC. > > > > [...] > > > >> > > >> > 5) Design considerations that are different from PCI: > >> > - Each driver implements its own scan and match function. PCI uses the > >> > BDF > >> >format to read the device from sysfs, but this _may_not_ be a case > >> > for a > >> >SoC ethernet device. > >> >= This is an important change from initial proposal by Jan in [2]. > >> > Unlike > >> >his attempt to use /sys/bus/platform, this patch relies on the PMD to > >> > > >> > >> It could be many redundant code if Each PMD driver has the scan > >> function if its own. > >> I think Jan's implementation is common to many platform drivers. > > > > I personally can find a use case for having a custom scan function. > > However, we should at least provide a default implementation. Probably, > > both the scan and match functions should be used to _override_ a default > > behaviour. So, only drivers that require to scan devices in a specific > > way would provide a custom function for this. > > > And for each platform/product > > > I agree, that this can sometimes lead to code duplication. Moreover, it > > opens door for a very non-standard, unsecure and wrong-by-design > > approaches. I'd like more to provide one or more scan implementations > > in EAL and do not put this responsibility on PMDs. > > > >> > >> >detect the devices. This is because SoC may require specific or > >> >additional info for device detection. Further, SoC may have embedded > > > > Can you provide an example for "additional info for device detection"? > > > >> > >> Can you give us more precise definition about SoC driver? Does it > >> include the driver in ARM server? > > > > I am sorry but I don't understand this question. > > > > What you mean by a "driver in ARM server"? Do you mean a kernel driver? > > > > There is no "SoC driver" in the text so what definition are asking for? > > > This patchset introduces rte_soc_driver, which is inheriting from rte_driver. > I want to know what devices can use this SoC driver/device framework. > Is it for the devices from ARM servers, or embedded systems of > different vendors? First, this is not an ARM-specific feature. Consider any MAC connected to the processor via some on-chip bus. In the world of ARM, it is usually a kind of AMBA bus. I think, the Intel Xeon with FPGA would be a good non-ARM example. Here they provide the Quick Path bus (but I don't know the details). So, you cannot access such device as PCI. It is usually not possible to distinguish the bus type easily (Linux calls this a platform device). So, an rte_soc_device denotes a device integrated on the chip (SoC, System-on-Chip). Such devices can have a lower access latency because they are closer to the processor. So, if you have a server system driver by a SoC with integrated MACs (no PCI-E involved), there is no way how to access them from DPDK. An rte_soc_device represents such devices and provides a way how to access them from DPDK. That is the goal... You can have an embedded device (router, switch, monitoring device, NAT, firewall, anything in a "small box" with high throughput demands) that perfectly fits into this SoC framework because it would be usually based on some SoC (ARM, ARM64, ...). > And this framework is too generalized, if we don't try to understand > "soc" in rte_soc_driver,
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 13:58:50 +0800 Jianbo Liu wrote: > On 9 September 2016 at 16:43, Shreyansh Jain > wrote: > > Introduction: > > = > > > > This patch set is direct derivative of Jan's original series [1],[2]. > > > > - As this deviates substantially from original series, if need be I can > >post it as a separate patch rather than v2. Please suggest. > > - Also, there are comments on original v1 ([4]) which are _not_ > >incorporated in this series as they refer to section no more in new > >version. > > - This v3 version is based on the rte_driver/device patchset v9 [10]. > >That series introduced device structures (rte_driver/rte_device) > >generalizing devices into PCI, VDEV, XXX. For the purpose of this > >patchset, XXX=>SOC. [...] > > > > 5) Design considerations that are different from PCI: > > - Each driver implements its own scan and match function. PCI uses the BDF > >format to read the device from sysfs, but this _may_not_ be a case for a > >SoC ethernet device. > >= This is an important change from initial proposal by Jan in [2]. Unlike > >his attempt to use /sys/bus/platform, this patch relies on the PMD to > > It could be many redundant code if Each PMD driver has the scan > function if its own. > I think Jan's implementation is common to many platform drivers. I personally can find a use case for having a custom scan function. However, we should at least provide a default implementation. Probably, both the scan and match functions should be used to _override_ a default behaviour. So, only drivers that require to scan devices in a specific way would provide a custom function for this. I agree, that this can sometimes lead to code duplication. Moreover, it opens door for a very non-standard, unsecure and wrong-by-design approaches. I'd like more to provide one or more scan implementations in EAL and do not put this responsibility on PMDs. > > >detect the devices. This is because SoC may require specific or > >additional info for device detection. Further, SoC may have embedded Can you provide an example for "additional info for device detection"? > > Can you give us more precise definition about SoC driver? Does it > include the driver in ARM server? I am sorry but I don't understand this question. What you mean by a "driver in ARM server"? Do you mean a kernel driver? There is no "SoC driver" in the text so what definition are asking for? > > >devices/MACs which require initialization which cannot be covered through > >sysfs parsing. I think, the description itself is incorrect. If a device's initialization cannot be satisfied vie sysfs, it means that you have to write a specific probe function. This is not related to scan in any way. However, there may be a group of devices which are not managed by the standard platform_driver of the Linux Kernel (or other OS). In that case, the custom scan function would be helpful. I can imagine a device in a fully I/O coherent platform that only requires to access the /dev/mem only (for the register space). It is unsecure but it would work without any OS-driver. However, I consider it a corner case. It can be useful for testing sometimes but not very helpful for production. We should however support mainly the standard devices which are always represented by the OS. Otherwise, such system would introduce security issues. > > I think it can be done in devinit, not in scan function. devinit can > be different for each driver. +1 > > >= PCI based PMDs rely on EAL's capability to detect devices. This > >proposal puts the onus on PMD to detect devices, add to soc_device_list > >and wait for Probe. Matching, of device<=>driver is again PMD's callback. > > Regards Jan -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v3 06/15] eal/soc: implement probing of drivers
On Fri, 9 Sep 2016 14:13:50 +0530
Shreyansh Jain wrote:
> Each SoC PMD registers a set of callback for scanning its own bus/infra and
> matching devices to drivers when probe is called.
> This patch introduces the infra for calls to SoC scan on rte_eal_soc_init()
> and match on rte_eal_soc_probe().
>
> Patch also adds test case for scan and probe.
>
> Signed-off-by: Jan Viktorin
> Signed-off-by: Shreyansh Jain
> Signed-off-by: Hemant Agrawal
> ---
> app/test/test_soc.c | 138 ++-
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 4 +
> lib/librte_eal/common/eal_common_soc.c | 215
>
> lib/librte_eal/common/include/rte_soc.h | 51 ++
> lib/librte_eal/linuxapp/eal/eal.c | 5 +
> lib/librte_eal/linuxapp/eal/eal_soc.c | 16 ++
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 4 +
> 7 files changed, 432 insertions(+), 1 deletion(-)
>
> diff --git a/app/test/test_soc.c b/app/test/test_soc.c
> index ac03e64..d2b9462 100644
> --- a/app/test/test_soc.c
> +++ b/app/test/test_soc.c
> @@ -87,14 +87,45 @@ static int test_compare_addr(void)
> */
> struct test_wrapper {
> struct rte_soc_driver soc_drv;
> + struct rte_soc_device soc_dev;
> };
>
> +static int empty_pmd0_devinit(struct rte_soc_driver *drv,
> + struct rte_soc_device *dev);
> +static int empty_pmd0_devuninit(struct rte_soc_device *dev);
I prefer an empty line here.
What is the prupose of the scan here? What device does it provide
to the test? I'd prefer to call it e.g. "allways_find_device0" or
something describing the purpose and explaining what is the goal
of the related test.
Probably a comment explaining "provide a device named 'empty_pmd0_dev'
would be helpful.
> +static void test_soc_scan_dev0_cb(void);
Similar here, something like "match_by_name".
> +static int test_soc_match_dev0_cb(struct rte_soc_driver *drv,
> + struct rte_soc_device *dev);
I prefer an empty line here.
ditto...
> +static void test_soc_scan_dev1_cb(void);
ditto...
> +static int test_soc_match_dev1_cb(struct rte_soc_driver *drv,
> + struct rte_soc_device *dev);
> +
> +static int
> +empty_pmd0_devinit(struct rte_soc_driver *drv __rte_unused,
> +struct rte_soc_device *dev __rte_unused)
> +{
> + return 0;
> +}
> +
> +static int
> +empty_pmd0_devuninit(struct rte_soc_device *dev)
> +{
> + /* Release the memory associated with dev->addr.name */
> + free(dev->addr.name);
> +
> + return 0;
> +}
> +
> struct test_wrapper empty_pmd0 = {
> .soc_drv = {
> .driver = {
> .name = "empty_pmd0"
> },
> - },
> + .devinit = empty_pmd0_devinit,
> + .devuninit = empty_pmd0_devuninit,
> + .scan_fn = test_soc_scan_dev0_cb,
> + .match_fn = test_soc_match_dev0_cb,
> + }
> };
>
> struct test_wrapper empty_pmd1 = {
> @@ -102,9 +133,54 @@ struct test_wrapper empty_pmd1 = {
> .driver = {
> .name = "empty_pmd1"
> },
> + .scan_fn = test_soc_scan_dev1_cb,
> + .match_fn = test_soc_match_dev1_cb,
> },
> };
>
> +static void
> +test_soc_scan_dev0_cb(void)
> +{
> + /* SoC's scan would scan devices on its bus and add to
> + * soc_device_list
> + */
> + empty_pmd0.soc_dev.addr.name = strdup("empty_pmd0_dev");
> +
> + TAILQ_INSERT_TAIL(_device_list, _pmd0.soc_dev, next);
> +}
> +
> +static int
> +test_soc_match_dev0_cb(struct rte_soc_driver *drv __rte_unused,
> +struct rte_soc_device *dev)
> +{
> + if (!dev->addr.name || strcmp(dev->addr.name, "empty_pmd0_dev"))
> + return 0;
> +
> + return 1;
> +}
> +
> +
> +static void
> +test_soc_scan_dev1_cb(void)
> +{
> + /* SoC's scan would scan devices on its bus and add to
> + * soc_device_list
> + */
> + empty_pmd0.soc_dev.addr.name = strdup("empty_pmd1_dev");
> +
> + TAILQ_INSERT_TAIL(_device_list, _pmd1.soc_dev, next);
> +}
> +
> +static int
> +test_soc_match_dev1_cb(struct rte_soc_driver *drv __rte_unused,
> +struct rte_soc_device *dev)
> +{
> + if (!dev->addr.name || strcmp(dev->addr.name, "empty_pmd1_dev"))
> + return 0;
> +
> + return 1;
> +}
> +
> static int
> count_registered_socdrvs(void)
> {
>
[dpdk-dev] [PATCH v10 05/25] crypto: no need for a crypto pmd type
On Fri, 16 Sep 2016 09:59:40 +0530 Shreyansh Jain wrote: > From: David Marchand > > This information is not used and just adds noise. > > Signed-off-by: David Marchand > Signed-off-by: Shreyansh Jain Reviewed-by: Jan Viktorin
[dpdk-dev] [PATCH v10 02/25] eal: remove duplicate function declaration
On Fri, 16 Sep 2016 09:59:37 +0530
Shreyansh Jain wrote:
> From: David Marchand
>
> rte_eal_dev_init is declared in both eal_private.h and rte_dev.h since its
> introduction.
> This function has been exported in ABI, so remove it from eal_private.h
>
> Fixes: e57f20e05177 ("eal: make vdev init path generic for both virtual and
> pci devices")
>
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
Reviewed-by: Jan Viktorin
[dpdk-dev] [PATCH v3 04/15] eal: introduce --no-soc option
Hello Shreyansh,
there was an objection to reverse this option from negative
to positive semantics:
http://dpdk.org/ml/archives/dev/2016-May/038953.html
As SoC infrastructure would to be experimental for some time,
I think it is a good idea to disable it as default.
Regards
Jan
On Fri, 9 Sep 2016 14:13:48 +0530
Shreyansh Jain wrote:
> This option has the same meaning for the SoC infra as the --no-pci
> for the PCI infra.
>
> Signed-off-by: Jan Viktorin
> Signed-off-by: Shreyansh Jain
> Signed-off-by: Hemant Agrawal
> ---
> lib/librte_eal/common/eal_common_options.c | 5 +
> lib/librte_eal/common/eal_internal_cfg.h | 1 +
> lib/librte_eal/common/eal_options.h| 2 ++
> 3 files changed, 8 insertions(+)
>
> diff --git a/lib/librte_eal/common/eal_common_options.c
> b/lib/librte_eal/common/eal_common_options.c
> index 1a1bab3..d97cf0a 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -85,6 +85,7 @@ eal_long_options[] = {
> {OPT_NO_HPET, 0, NULL, OPT_NO_HPET_NUM },
> {OPT_NO_HUGE, 0, NULL, OPT_NO_HUGE_NUM },
> {OPT_NO_PCI,0, NULL, OPT_NO_PCI_NUM },
> + {OPT_NO_SOC,0, NULL, OPT_NO_SOC_NUM },
> {OPT_NO_SHCONF, 0, NULL, OPT_NO_SHCONF_NUM},
> {OPT_PCI_BLACKLIST, 1, NULL, OPT_PCI_BLACKLIST_NUM},
> {OPT_PCI_WHITELIST, 1, NULL, OPT_PCI_WHITELIST_NUM},
> @@ -855,6 +856,10 @@ eal_parse_common_option(int opt, const char *optarg,
> conf->no_pci = 1;
> break;
>
> + case OPT_NO_SOC_NUM:
> + conf->no_soc = 1;
> + break;
> +
> case OPT_NO_HPET_NUM:
> conf->no_hpet = 1;
> break;
> diff --git a/lib/librte_eal/common/eal_internal_cfg.h
> b/lib/librte_eal/common/eal_internal_cfg.h
> index 5f1367e..3a98e94 100644
> --- a/lib/librte_eal/common/eal_internal_cfg.h
> +++ b/lib/librte_eal/common/eal_internal_cfg.h
> @@ -67,6 +67,7 @@ struct internal_config {
> unsigned hugepage_unlink; /**< true to unlink backing files */
> volatile unsigned xen_dom0_support; /**< support app running on Xen
> Dom0*/
> volatile unsigned no_pci; /**< true to disable PCI */
> + volatile unsigned no_soc; /**< true to disable SoC */
> volatile unsigned no_hpet;/**< true to disable HPET */
> volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping
>
> * instead of native TSC */
> diff --git a/lib/librte_eal/common/eal_options.h
> b/lib/librte_eal/common/eal_options.h
> index a881c62..ba1e704 100644
> --- a/lib/librte_eal/common/eal_options.h
> +++ b/lib/librte_eal/common/eal_options.h
> @@ -69,6 +69,8 @@ enum {
> OPT_NO_HUGE_NUM,
> #define OPT_NO_PCI"no-pci"
> OPT_NO_PCI_NUM,
> +#define OPT_NO_SOC"no-soc"
> + OPT_NO_SOC_NUM,
> #define OPT_NO_SHCONF "no-shconf"
> OPT_NO_SHCONF_NUM,
> #define OPT_SOCKET_MEM"socket-mem"
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v3 02/15] eal/soc: add rte_eal_soc_register/unregister logic
On Thu, 15 Sep 2016 14:00:25 +0100 "Hunt, David" wrote: > > new file mode 100644 > > index 000..56135ed > > --- /dev/null > > +++ b/lib/librte_eal/common/eal_common_soc.c > > @@ -0,0 +1,56 @@ > > +/*- > > + * BSD LICENSE > > + * > > + * Copyright(c) 2016 RehiveTech. All rights reserved. > > + * All rights reserved. > > Duplicate "All rights reserved" This is present in many source files in DPDK... I don't know why. lib/librte_eal/common/eal_common_pci.c lib/librte_eal/common/eal_common_dev.c ... Jan > > > + * > > + * Redistribution and use in source and binary forms, with or without > > + * modification, are permitted provided that the following conditions > > + * are met: > > + * > > + * * Redistributions of source code must retain the above copyright > > + * notice, this list of conditions and the following disclaimer. > > + * * Redistributions in binary form must reproduce the above copyright > > + * notice, this list of conditions and the following disclaimer in > > + * the documentation and/or other materials provided with the > > + * distribution. > > + * * Neither the name of RehiveTech nor the names of its > > + * contributors may be used to endorse or promote products derived > > + * from this software without specific prior written permission. > > + *
[dpdk-dev] [PATCH v8 00/25] Introducing rte_driver/rte_device generalization
Hi Shreyansh,
I am sorry to be quiet on this thread. I am traveling in those
two weeks and have some vacation. However, I passively follow the
conversation. Thank you for your work so far!
Regards
Jan
On Fri, 26 Aug 2016 19:26:38 +0530
Shreyansh Jain wrote:
> Based on master (e22856313fff2)
>
> Background:
> ===
>
> It includes two different patch-sets floated on ML earlier:
> * Original patch series is from David Marchand [1], [2].
> `- This focused mainly on PCI (PDEV) part
> `- v7 of this was posted by me [8] in August/2016
> * Patch series [4] from Jan Viktorin
> `- This focused on VDEV and rte_device integration
>
> Introduction:
> =
>
> This patch series introduces a generic device model, moving away from PCI
> centric code layout. Key change is to introduce rte_driver/rte_device
> structures at the top level which are inherited by
> rte_XXX_driver/rte_XXX_device - where XXX belongs to {pci, vdev, soc (in
> future),...}.
>
> Key motivation for this series is to move away from PCI centric design of
> EAL to a more hierarchical device model - pivoted around a generic driver
> and device. Each specific driver and device can inherit the common
> properties of the generic set and build upon it through driver/device
> specific functions.
>
> Earlier, the EAL device initialization model was:
> (Refer: [3])
>
> --
> Constructor:
> |- PMD_DRIVER_REGISTER(rte_driver)
> `- insert into dev_driver_list, rte_driver object
>
> rte_eal_init():
> |- rte_eal_pci_init()
> | `- scan and fill pci_device_list from sysfs
> |
> |- rte_eal_dev_init()
> | `- For each rte_driver in dev_driver_list
> | `- call the rte_driver->init() function
> ||- PMDs designed to call rte_eth_driver_register(eth_driver)
> ||- eth_driver have rte_pci_driver embedded in them
> |`- rte_eth_driver_register installs the
> | rte_pci_driver->devinit/devuninit callbacks.
> |
> |- rte_eal_pci_probe()
> | |- For each device detected, dev_driver_list is parsed and matching is
> | | done.
> | |- For each matching device, the rte_pci_driver->devinit() is called.
> | |- Default map is to rte_eth_dev_init() which in turn creates a
> | | new ethernet device (eth_dev)
> | | `- eth_drv->eth_dev_init() is called which is implemented by
> `--|individual PMD drivers.
>
> --
>
> The structure of driver looks something like:
>
> ++ ._.
> | rte_driver <-| PMD |___
> | .init | `-` \
> +.---+ | \
> `-.| What PMD actually is
> \ | |
> +--v+ |
> | eth_driver| |
> | .eth_dev_init | |
> +.--+ |
>`-. |
> \ |
>+v---+
>| rte_pci_driver |
>| .pci_devinit |
>++
>
> and all devices are part of a following linked lists:
> - dev_driver_list for all rte_drivers
> - pci_device_list for all devices, whether PCI or VDEV
>
>
> From the above:
> * a PMD initializes a rte_driver, eth_driver even though actually it is a
>pci_driver
> * initialization routines are passed from rte_driver->pci_driver->eth_driver
>even though they should ideally be rte_eal_init()->rte_pci_driver()
> * For a single driver/device type model, this is not necessarily a
>functional issue - but more of a design language.
> * But, when number of driver/device type increase, this would create problem
>in how driver<=>device links are represented.
>
> Proposed Architecture:
> ==
>
> A nice representation has already been created by David in [3]. Copying that
> here:
>
> +--+ +---+
> | | | |
> | rte_pci_device | | rte_pci_driver|
> | | | |
> +-+ | +--+ | | +---+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-> rte_driver| |
> | | | | char name[] | | | | char name[] | |
> +-+ | | | | | | int init(rte_device *) | |
> | +--+ | | | i
[dpdk-dev] [PATCH] eal/armv8: high-resolution cycle counter
> > + * asm volatile("msr pmuserenr_el0, %0" : : "r"(BIT(0) | BIT(2)));
> > > + * asm volatile("mrs %0, pmcr_el0" : "=r" (val));
> > > + * val |= (BIT(0) | BIT(2));
> > > + * isb();
> > > + * asm volatile("msr pmcr_el0, %0" : : "r" (val));
> >
> > In your git repo I see that on cleanup the cycle count register is not
> > disabled (PMCNTENCLR_EL0). It shall be better to disable the cycle count
> > register too at module exit.
>
> OK
+1
I've got a private kernel driver enabling and disabling (hopefully) properly
this for ARMv7. If we'd like to merge it, I'd like to have a single module
or at least single module with 2 implementations...
I can post it if it would be helpful.
Regards
Jan
>
> >
> > > + *
> > > + */
> > > +static inline uint64_t
> > > +rte_rdtsc(void)
> > > +{
> > > + uint64_t tsc;
> > > +
> > > + asm volatile("mrs %0, pmccntr_el0" : "=r"(tsc));
> > > + return tsc;
> > > +}
> > > +#endif
> > >
> > > static inline uint64_t
> > > rte_rdtsc_precise(void)
> > > --
> > > 2.5.5
> >
> > Do you also plan to support performance monitor event counters?
>
> No. This patch was inspired by armv7 PMU scheme and its part of DPDK.
> The sole reason to add this support to catch any performance regression
> through app/test application.Other than that, I think cntvct_el0 based
> existing scheme is good enough for all the use cases.
>
> >
> > Regards,
> > Nipun
> >
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] DPDK support for on system bus connected embedded MAC
Hello, On Sat, 06 Aug 2016 15:19:16 +0200 Thomas Monjalon wrote: > Hi, > > 2016-08-05 16:26, Venkat Karthik K: > > Hello, > > > > I am planning to develop Poll Mode Driver for new embedded MAC which is > > connected on system bus. > > Could you please provide more details about what you are working on? I am interested as well... > > > I am looking into available poll mode drivers > > support for different Network cards in DPDK 16.07 package but all of them > > are connected and managed by PCI bus. > > Yes, DPDK was historically PCI-centric. > The release 16.11 will see a good rework of the device management and > it could hopefully be possible to implement PMDs for other buses. > > > Is there DPDK support for embedded Ethernet/MAC which is connected on > > system bus , please point me support which will help a lot for my > > development . > > Please check the work of Jan Viktorin: > http://dpdk.org/dev/patchwork/project/dpdk/list/?submitter=292=* > Some review would be welcome :) Thanks The patchset has very low number of reviews. If you have any specific requirements or ideas how to improve it you are welcome to comment. I'll try to rebase it on the latest HEAD as soon as I find some time (I hope in few days). I also have some non-public patches for VFIO and UIO support which I would like to include. Regards Jan -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] test: failed to clone dpdk source in windows
On Fri, 05 Aug 2016 09:51:06 +0200 Thomas Monjalon wrote: > 2016-08-05 09:44, Thomas Monjalon: > > 2016-08-05 10:09, linhaifeng: > > > hi,thomas > > > > > > Could you change the name of file in directory > > > app/test/test_pci_sysfs/bus/pci/devices/ ? > > > I think somebody like us also cann't access internet in liunux.Windows > > > not support file name > > > include ':'. Hello, I am sorry for this situation but (as Thomas mentioned below) Windows is not considered as a supported platform. If you have issues with this approach you are welcome to prepare some patch changing this to do the same thing in another way. There was a discussion when accepting the fake sysfs into DPDK on the public mailing list. I did not received any serious complaints at that time. Regards Jan > > > > Not sure to understand the use case. > > This is a fake sysfs, we cannot change the names. > > In other words, Windows is not supported, neither for runtime > nor for development. > For information, which filesystem do not support ':'? > > If someone wants to add this support, the fake sysfs could have slightly > different names and rightly renamed during compilation. -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v7 00/17] Prepare for rte_device / rte_driver
Thank you. Hope to find some time this week to do my part. Jan On Mon, 1 Aug 2016 16:15:15 +0530 Shreyansh Jain wrote: > * Original patch series is from David Marchand [1], [2]. > * Link with patch series [4] from Jan Viktorin for a more complete picture > of proposed EAL device heirarchy changes. > * This might not be in-sync with pmdinfogen as PMD_REGISTER_DRIVER is > removed [7]. > > David created the original patchset based on the discussions on list [3]. > Being a large piece of work, this patchset introduces first level of changes > for generalizing the driver-device relationship for supporting hotplug. > > Overview of this work as per David [3], as well as notes from Thomas [9] & > Jan: > - pdev -> PCI registeration using helpers (introduced in this series) > - removal of eth/crypto driver registeration callbacks. These are now handled > by PCI registeration helpers (this patch) > - rte_device=>pci/vdev device heirarchy (by this [4] series) > - removal of PMD_PDEV type (this patch) and PMD_VDEV (by this [4] series) > - Support for hotplugging > > This patchset is based on master (b0a1419) > > [1] http://dpdk.org/ml/archives/dev/2016-January/032387.html > [2] http://dpdk.org/ml/archives/dev/2016-April/037686.html > [3] http://dpdk.org/ml/archives/dev/2016-January/031390.html > [4] http://dpdk.org/ml/archives/dev/2016-July/043645.html > [5] http://dpdk.org/ml/archives/dev/2016-June/042439.html > [6] http://dpdk.org/ml/archives/dev/2016-June/042444.html > [7] http://dpdk.org/ml/archives/dev/2016-July/043172.html > [8] http://dpdk.org/ml/archives/dev/2016-July/044004.html > [9] http://dpdk.org/ml/archives/dev/2016-July/044086.html > > Changes since v6: > - rebase over 16.07 (b0a1419) > - DRIVER_REGISTER_PCI macro is now passed pci_drv rather than drv > - review comments regarding missing information in log messages > - new API additions to 16.11 map objects > - review comment in [5] and [7] are not included in this series. > > Changes since v5: > - Rebase over master (11c5e45d8) > - Rename RTE_EAL_PCI_REGISTER helper macro to DRIVER_REGISTER_PCI to be in > sync > with DRIVER_REGISTER_PCI_TABLE. [Probably, in future, both can be merged] > - Modifications to bnxt and thunderx driver PMD registeration files for > using the simplified PCI device registeration helper macro > > Changes since v4: > - Fix compilation issue after rebase on HEAD (913154e) in previous series > - Retain rte_eth_dev_get_port_by_name and rte_eth_dev_get_name_by_port which > were removed by previous patchset. These are being used by pdump library > > Changes since v3: > - rebase over HEAD (913154e) > - Update arguments to RTE_EAL_PCI_REGISTER macro as per Jan's suggestion > - modify qede driver to use RTE_EAL_PCI_REGISTER > - Argument check in hotplug functions > > Changes since v2: > - rebase over HEAD (d76c193) > - Move SYSFS_PCI_DRIVERS macro to rte_pci.h to avoid compilation issue > > Changes since v1: > - rebased on HEAD, new drivers should be okay > - patches have been split into smaller pieces > - RTE_INIT macro has been added, but in the end, I am not sure it is useful > - device type has been removed from ethdev, as it was used only by hotplug > - getting rid of pmd type in eal patch (patch 5 of initial series) has been > dropped for now, we can do this once vdev drivers have been converted > > David Marchand, Shreyansh Jain (17): > pci: no need for dynamic tailq init > crypto: no need for a crypto pmd type > drivers: align pci driver definitions > eal: remove duplicate function declaration > eal: introduce init macros > crypto: export init/uninit common wrappers for pci drivers > ethdev: export init/uninit common wrappers for pci drivers > drivers: convert all pdev drivers as pci drivers > crypto: get rid of crypto driver register callback > ethdev: get rid of eth driver register callback > eal/linux: move back interrupt thread init before setting affinity > pci: add a helper for device name > pci: add a helper to update a device > ethdev: do not scan all pci devices on attach > eal: add hotplug operations for pci and vdev > ethdev: convert to eal hotplug > ethdev: get rid of device type > > app/test/virtual_pmd.c | 2 +- > drivers/crypto/qat/rte_qat_cryptodev.c | 18 +- > drivers/net/af_packet/rte_eth_af_packet.c | 2 +- > drivers/net/bnx2x/bnx2x_ethdev.c| 34 +-- > drivers/net/bnxt/bnxt_ethdev.c | 16 +- > drivers/net/bonding/rte_eth_bond_api.c | 2 +- > drivers/net/cxgbe/cxgbe_ethdev.c| 24 +-- > drivers/net/cxgbe/cxgbe_main.c | 2 +-
[dpdk-dev] [PATCH v6 05/17] eal: introduce init macros
On Thu, 28 Jul 2016 15:06:10 +0530 Shreyansh Jain wrote: > Hi Jan, > > On Friday 15 July 2016 04:18 PM, Shreyansh jain wrote: > > On Thursday 14 July 2016 09:27 PM, Jan Viktorin wrote: [...] > >>>>> (drv).name = RTE_STR(nm); > >>> > >>> That is a miss from my side. > >>> I will publish v7 with this. You want this right away or should I wait a > >>> little while (more reviews, or any pending additions as per Thomas's > >>> notes) before publishing? > >> > >> Please. The time is almost gone. 18/7/2016 is the release (according > >> to the roadmap)... I have to fix it in my patchset, otherwise it > >> does not build (after moving the .name from rte_pci_driver to > >> rte_driver). > >> > > > > I didn't consider 18/Jul. > > Please go ahead. I will continue to send v7 _without_ the above change so > > that your patchset doesn't break. This way you will not get blocked because > > of me. > > > > Now that we have already skipped the 16.07, I will fix this in my code and > release an updated version as soon as 16.07 is officially available. Is that > OK? Sure :). The thing is that during August-September, I've got significantly less time for this then in June-July :/. That's why I was trying to fit in the 16.07. > > Also, I have fixed most review comments except [1]. I am still not sure of > the impact of this change. So, I will publish the v7 without this and then > probably a v8 in case this change has any impact. I have no idea about this. Hopefully, it's not a very serious thing. > That way we can have your patchset not blocked because of this series. Thank you! > > [1] http://dpdk.org/ml/archives/dev/2016-July/044004.html > > [...] > > > - > Shreyansh -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] doc: announce ivshmem support removal
On Wed, 20 Jul 2016 18:35:46 +0200 Thomas Monjalon wrote: > There was a prior call with an explanation of what needs to be done: > http://dpdk.org/ml/archives/dev/2016-June/040844.html > - Qemu patch upstreamed > - IVSHMEM PCI device managed by a PCI driver > - No DPDK objects (ring/mempool) allocated by EAL > > As nobody seems interested, it is time to remove this code which > makes EAL improvements harder. > > Signed-off-by: Thomas Monjalon > Acked-by: David Marchand > Acked-by: Maxime Coquelin Acked-by: Jan Viktorin
[dpdk-dev] doc: deprecate vhost-cuse
On Fri, 15 Jul 2016 20:28:33 +0800 Yuanhan Liu wrote: > Vhost-cuse was invented before vhost-user exist. The both are actually > doing the same thing: a vhost-net implementation in user space. But they > are not exactly the same thing. > > Firstly, vhost-cuse is harder for use; no one seems to care it, either. > Furthermore, since v2.1, a large majority of development effort has gone > to vhost-user. For example, we extended the vhost-user spec to add the > multiple queue support. We also added the vhost-user live migration at > v16.04 and the latest one, vhost-user reconnect that allows vhost app > restart without restarting the guest. Both of them are very important > features for product usage and none of them works for vhost-cuse. > > You now see that the difference between vhost-user and vhost-cuse is > big (and will be bigger and bigger as time moves forward), that you > should never use vhost-cuse, that we should drop it completely. > > The remove would also result to a much cleaner code base, allowing us > to do all kinds of extending easier. > > So here to mark vhost-cuse as deprecated in this release and will be > removed in the next release (v16.11). > > Signed-off-by: Yuanhan Liu > Acked-by: Ciara Loftus > Acked-by: Thomas Monjalon > Acked-by: Rich Lane Acked-by: Jan Viktorin
[dpdk-dev] doc: announce renaming of ethdev library
On Tue, 26 Jul 2016 18:22:21 +0200 Thomas Monjalon wrote: > The right name of ethdev should be dpdk_netdev. However: > 1/ We are using rte_ prefix in the code and library names. > 2/ The API uses rte_ethdev > That's why 16.11 will just have the rte_ prefix prepended to > the library filename as every other libraries. > > Signed-off-by: Thomas Monjalon > Acked-by: Jan Viktorin
[dpdk-dev] [PATCH v1 00/15] rte_driver/device infrastructure
On Fri, 15 Jul 2016 15:19:14 +0200 Thomas Monjalon wrote: > 2016-07-08 21:09, Jan Viktorin: > > Hello, > > > > based on the discussions with Shreyansh, I propose a patchset with > > the important EAL changes. It is incomplete and I suppose to extend > > and change certain things in the foreseeable future. > > > > Important notes: > > > > * pmd_type is removed > > * introduced rte_vdev_driver inheriting rte_driver > > * PMD_REGISTER_DRIVER is replaced by RTE_EAL_VDRV_REGISTER > > * rte_driver/device integrated into rte_pci_driver/device > > * all drivers and devices are in 2 lists - general and bus-specific > > > > Shreyansh, I hope I do not duplicate your work. I tried to avoid touching > > pmd_type but it quite complicated... There is also an initial generalization > > of rte_pci_resource. More such generalizations are to be done. > > > > The init/uninit functions cannot be generalized easily, I think. Both PCI > > and VDEV have different requirements. > > > > No idea about hotplug... > > Please could you give a clear overview of how you split the work in > your respective series? Yes, it's a bit messy... My quick summary follows. > > I take the opportunity to put my notes about some initial targets of > this refactoring: > > module/drivers > attached to 1 bus: pci_driver or vdev_driver pci_driver is done by Shreyansh/David vdev_driver is done by myself > rte_device = device resources / embedded in pci/vdev_driver Extraction of rte_device is done by myself > attached to n device interfaces (ethdev, crypto) > 1 device resource -> n device interfaces I am not sure, what those two points means exactly. > hotplug resource -> lookup drivers list > per-bus lists or 1 list? Not sure. At least partially done by Shreyansh/David. > devinit/devuninit generalized and moved to rte_driver > -> rename to probe/remove Some renames done by Shreyansh/David. There will be no move. The vdev_driver has different kind of init/uninit then PCI. So I cannot see a simple way how to generalize this. I'll do the final init->probe, uninit->remove renames. > crypto.dev_type could be dropped I am not sure about this. > drv_flags should be moved to rte_driver I'll do. > intr_init can be moved earlier in init, before affinity set > devices Done by Shreyansh/David. > unique_device_name -> standard naming? Done for PCI: rte_eal_pci_device_name by Shreyansh/David. > difference with port_id ? -> device id for ethdev Not sure. > should be unique_resource_name -> 1 EAL resource may match > several devices Not sure. > ethdev manage an interface, eal manage a hardware resource, device > object in between? Not sure about the question. > need for bus object? I don't think so at this stage. > no need of driver object, module object? The current rte_driver will not exist. Same for any kind of module. > devargs, intr_handle, numa_node should be moved to rte_device Yes, done by myself. > hotplug notification to do > notify free-able ressource? > remove blacklist at EAL level and let application handle it > devargs still in hotplug function, must be moved in separate API > devargs > new API > new command line parameters > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v6 12/17] pci: add a helper for device name
On Fri, 15 Jul 2016 11:56:38 +0200 Thomas Monjalon wrote: > 2016-07-15 15:09, Shreyansh jain: > > On Thursday 14 July 2016 10:25 PM, Jan Viktorin wrote: > > > What is meant by "resources" here? > > > > This has historic context (from earlier version of this patch). > > But I could relate the word 'resources' to EAL representation of devices - > > whether PCI or Crypto. > > Or, Resource == Device. > > We need to define a precise wording, especially for the words > - interface > - resource > - device > - driver > - module > Following are my thoughts: > > An interface is a view of a resource through an API (e.g. an ethdev port). > A resource is a well identified hardware (e.g. a PCI device id). > A device is a hardware function (e.g. a networking port). > Note that some PCI NICs have only one PCI device id for several ports > (Chelsio and Mellanox cases). That's why we need to distinguish device > and resource. > > A driver is the code handling a device. > I have read the word module in some patch proposals but I don't really know > what it refers to. Is it a group of drivers in the same file/directory? Well, yes, initially there was proposed a kind of module. However, after David as sent the patchset prepare for rte_device/driver, you can see that there is no need for such object (probably). A module might be helpful when thinking about the metadata (as done by Neil Horman). But as far as I know there was no need for this... So a module has no data abstraction now and I am not going to make any. Jan
[dpdk-dev] [PATCH v6 16/17] ethdev: convert to eal hotplug
On Fri, 15 Jul 2016 16:06:25 +0530
Shreyansh jain wrote:
> On Thursday 14 July 2016 10:21 PM, Jan Viktorin wrote:
> > On Tue, 12 Jul 2016 11:31:21 +0530
> > Shreyansh Jain wrote:
> >
> >> Remove bus logic from ethdev hotplug by using eal for this.
> >>
> >> Current api is preserved:
> >> - the last port that has been created is tracked to return it to the
> >> application when attaching,
> >> - the internal device name is reused when detaching.
> >>
> >> We can not get rid of ethdev hotplug yet since we still need some mechanism
> >> to inform applications of port creation/removal to substitute for ethdev
> >> hotplug api.
> >>
> >> dev_type field in struct rte_eth_dev and rte_eth_dev_allocate are kept as
> >> is, but this information is not needed anymore and is removed in the
> >> following
> >> commit.
> >>
> >> Signed-off-by: David Marchand
> >> Signed-off-by: Shreyansh Jain
> >> ---
> >> lib/librte_ether/rte_ethdev.c | 207
> >> +++---
> >> 1 file changed, 33 insertions(+), 174 deletions(-)
> >>
> >> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> >> index a667012..8d14fd7 100644
> >> --- a/lib/librte_ether/rte_ethdev.c
> >> +++ b/lib/librte_ether/rte_ethdev.c
> >> @@ -72,6 +72,7 @@
> >> static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
> >> struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
> >> static struct rte_eth_dev_data *rte_eth_dev_data;
> >> +static uint8_t eth_dev_last_created_port;
> >> static uint8_t nb_ports;
> >>
> >
> > [...]
> >
> >> -
> >> /* attach the new device, then store port_id of the device */
> >> int
> >> rte_eth_dev_attach(const char *devargs, uint8_t *port_id)
> >> {
> >> - struct rte_pci_addr addr;
> >>int ret = -1;
> >> + int current = eth_dev_last_created_port;
> >> + char *name = NULL;
> >> + char *args = NULL;
> >>
> >>if ((devargs == NULL) || (port_id == NULL)) {
> >>ret = -EINVAL;
> >>goto err;
> >>}
> >>
> >> - if (eal_parse_pci_DomBDF(devargs, ) == 0) {
> >> - ret = rte_eth_dev_attach_pdev(, port_id);
> >> - if (ret < 0)
> >> - goto err;
> >> - } else {
> >> - ret = rte_eth_dev_attach_vdev(devargs, port_id);
> >> - if (ret < 0)
> >> - goto err;
> >> + /* parse devargs, then retrieve device name and args */
> >> + if (rte_eal_parse_devargs_str(devargs, , ))
> >> + goto err;
> >> +
> >> + ret = rte_eal_dev_attach(name, args);
> >> + if (ret < 0)
> >> + goto err;
> >> +
> >> + /* no point looking at eth_dev_last_created_port if no port exists */
> >
> > I am not sure about this comment. What is "no point"?
> >
> > Isn't this also a potential bug? (Like the one below.) How could it
> > happen there is no port after a successful attach?
>
> Yes, even searching through code path I couldn't find a positive case where
> control would reach here without nb_ports>0.
> Though, i am not sure if some rough application attempts to mix-up calls -
> and that, in my opinion, is not worth checking.
> Should I remove it?
At least a loud log might be helpful. If there is really no path to reach this
point, I'd put RTE_VERIFY here.
>
> >
> >> + if (!nb_ports) {
> >> + ret = -1;
> >> + goto err;
> >> + }
> >> + /* if nothing happened, there is a bug here, since some driver told us
> >> + * it did attach a device, but did not create a port */
> >> + if (current == eth_dev_last_created_port) {
> >> + ret = -1;
> >> + goto err;
> >
> > Should we log this? Or call some kind panic?
>
> I will place a log because applications should have a chance to ignore a
> device which cannot be attached for whatever reason.
OK, we just should shout loudly if it means a bug...
[...]
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v6 12/17] pci: add a helper for device name
On Fri, 15 Jul 2016 15:09:58 +0530
Shreyansh jain wrote:
> On Thursday 14 July 2016 10:25 PM, Jan Viktorin wrote:
> > On Tue, 12 Jul 2016 11:31:17 +0530
> > Shreyansh Jain wrote:
> >
> >> eal is a better place than crypto / ethdev for naming resources.
> >
> > s/for naming/to name/
>
> OK.
>
> >
> > What is meant by "resources" here?
>
> This has historic context (from earlier version of this patch).
> But I could relate the word 'resources' to EAL representation of devices -
> whether PCI or Crypto.
> Or, Resource == Device.
If it is possible I'd like more "device". But I think it's not that critical
thing...
>
> >
> >> Add a helper in eal and make use of it in crypto / ethdev.
[...]
> >> TAILQ_HEAD(pci_device_list, rte_pci_device); /**< PCI devices in D-linked
> >> Q. */
> >> @@ -95,6 +96,7 @@ const char *pci_get_sysfs_path(void);
> >>
> >> /** Formatting string for PCI device identifier: Ex: :00:01.0 */
> >> #define PCI_PRI_FMT "%.4" PRIx16 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
> >> +#define PCI_PRI_STR_SIZE sizeof(":XX:XX.X")
> >>
> >> /** Short formatting string, without domain, for PCI device: Ex: 00:01.0
> >> */
> >> #define PCI_SHORT_PRI_FMT "%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
> >> @@ -308,6 +310,29 @@ eal_parse_pci_DomBDF(const char *input, struct
> >> rte_pci_addr *dev_addr)
> >> }
> >> #undef GET_PCIADDR_FIELD
> >>
> >> +/**
> >> + * Utility function to write a pci device name, this device name can
> >> later be
> >> + * used to retrieve the corresponding rte_pci_addr using above functions.
> >>
> >
> > What about saying "using functions eal_parse_pci_*BDF"? The
> > specification "above" is quite uncertain...
>
> Agree that 'above' is positional word and should be avoided.
> I will change that to "... using eal_parse_pci_* BDF helpers". OK?
OK.
[...]
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] spinlock: Move constructor function out of header file
Hello Damjan,
thank you for the patch. It makes sense to me.
Next time, please CC the appropriate maintainers.
(See the MAINTAINERS file in the root of the DPDK source tree.)
In the subject after "spinlock:" you should start with a lower case
letter, so "move constructor..."
On Thu, 14 Jul 2016 15:27:29 +0200
damarion at cisco.com wrote:
> From: Damjan Marion
>
> Having constructor function in the header gile is generaly
I'd write:
Having constructor functions in header files is generally a bad idea.
Anyway:
s/gile/file/
> bad idea, as it will eventually be implanted to 3rd party
> library.
>
> In this case it is causing linking issues with 3rd party
it causes linking issues
> libraries when application is not linked to dpdk, due to missing
an application
to dpdk due to a missing gymbol (no comma)
> symbol called by constructor.
Please include the following line:
Fixes: ba7468997ea6 ("spinlock: add HTM lock elision for x86")
>
> Signed-off-by: Damjan Marion
>
> ---
> lib/librte_eal/common/arch/x86/rte_spinlock.c | 45 ++
> .../common/include/arch/x86/rte_spinlock.h | 13 ++-
> lib/librte_eal/linuxapp/eal/Makefile | 1 +
> 3 files changed, 49 insertions(+), 10 deletions(-)
> create mode 100644 lib/librte_eal/common/arch/x86/rte_spinlock.c
>
> diff --git a/lib/librte_eal/common/arch/x86/rte_spinlock.c
> b/lib/librte_eal/common/arch/x86/rte_spinlock.c
> new file mode 100644
> index 000..ad8cc5a
> --- /dev/null
> +++ b/lib/librte_eal/common/arch/x86/rte_spinlock.c
> @@ -0,0 +1,45 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include "rte_cpuflags.h"
> +
> +#include
According to:
http://dpdk.org/doc/guides-16.04/contributing/coding_style.html#coding-style
you should change the order of these includes.
> +
> +uint8_t rte_rtm_supported; /* cache the flag to avoid the overhead
> + of the rte_cpu_get_flag_enabled function */
The comment should be placed before the declaration or use the /**< */
Doxygen style. I'd prefer to placed it before. Can you fix it with this
patch?
> +
> +static void __attribute__((constructor))
> +rte_rtm_init(void)
> +{
> + rte_rtm_supported = rte_cpu_get_flag_enabled(RTE_CPUFLAG_RTM);
> +}
> diff --git a/lib/librte_eal/common/include/arch/x86/rte_spinlock.h
> b/lib/librte_eal/common/include/arch/x86/rte_spinlock.h
> index 02f95cb..8e630c2 100644
> --- a/lib/librte_eal/common/include/arch/x86/rte_spinlock.h
> +++ b/lib/librte_eal/common/include/arch/x86/rte_spinlock.h
> @@ -94,24 +94,17 @@ rte_spinlock_trylock (rte_spinlock_t *sl)
> }
> #endif
>
> -static uint8_t rtm_supported; /* cache the flag to avoid the overhead
> - of the rte_cpu_get_flag_enabled function */
> -
> -static inline void __attribute__((constructor))
> -rte_rtm_init(void)
> -{
> - rtm_supported = rte_cpu_get_flag_enabled(RTE_CPUFLAG_RTM);
> -}
> +extern uint8_t rte_rtm_supported;
>
> static inline int rte_tm_supported(void)
> {
> - return rtm_supported;
> + return rte_rtm_supported;
> }
>
> static inline int
> rte_try_tm(volatile int *lock)
> {
> - if (!rtm_supported)
> + if (!rte_rtm_supported)
> return 0;
[dpdk-dev] [PATCH v6 13/17] pci: add a helper to update a device
t; --- a/lib/librte_eal/linuxapp/eal/eal_pci.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
> @@ -417,6 +417,19 @@ pci_scan_one(const char *dirname, uint16_t domain,
> uint8_t bus,
> return 0;
> }
>
> +int
> +pci_update_device(const struct rte_pci_addr *addr)
> +{
> + char filename[PATH_MAX];
> +
> + snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
> + SYSFS_PCI_DEVICES, addr->domain, addr->bus, addr->devid,
Use pci_get_sysfs_path here.
> + addr->function);
> +
> + return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
> + addr->function);
> +}
> +
> /*
> * split up a pci address into its constituent parts.
> */
--
Jan ViktorinE-mail: Viktorin at RehiveTech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v6 12/17] pci: add a helper for device name
On Tue, 12 Jul 2016 11:31:17 +0530
Shreyansh Jain wrote:
> eal is a better place than crypto / ethdev for naming resources.
s/for naming/to name/
What is meant by "resources" here?
> Add a helper in eal and make use of it in crypto / ethdev.
>
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
> ---
> lib/librte_cryptodev/rte_cryptodev.c| 27 ---
> lib/librte_eal/common/include/rte_pci.h | 25 +
> lib/librte_ether/rte_ethdev.c | 24
> 3 files changed, 33 insertions(+), 43 deletions(-)
>
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> b/lib/librte_cryptodev/rte_cryptodev.c
> index d7be111..60c6384 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -367,23 +367,6 @@ rte_cryptodev_pmd_allocate(const char *name, int
> socket_id)
> return cryptodev;
> }
>
> -static inline int
> -rte_cryptodev_create_unique_device_name(char *name, size_t size,
> - struct rte_pci_device *pci_dev)
> -{
> - int ret;
> -
> - if ((name == NULL) || (pci_dev == NULL))
> - return -EINVAL;
> -
> - ret = snprintf(name, size, "%d:%d.%d",
> - pci_dev->addr.bus, pci_dev->addr.devid,
> - pci_dev->addr.function);
> - if (ret < 0)
> - return ret;
> - return 0;
> -}
> -
> int
> rte_cryptodev_pmd_release_device(struct rte_cryptodev *cryptodev)
> {
> @@ -446,9 +429,8 @@ rte_cryptodev_pci_probe(struct rte_pci_driver *pci_drv,
> if (cryptodrv == NULL)
> return -ENODEV;
>
> - /* Create unique Crypto device name using PCI address */
> - rte_cryptodev_create_unique_device_name(cryptodev_name,
> - sizeof(cryptodev_name), pci_dev);
> + rte_eal_pci_device_name(_dev->addr, cryptodev_name,
> + sizeof(cryptodev_name));
>
> cryptodev = rte_cryptodev_pmd_allocate(cryptodev_name, rte_socket_id());
> if (cryptodev == NULL)
> @@ -503,9 +485,8 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
> if (pci_dev == NULL)
> return -EINVAL;
>
> - /* Create unique device name using PCI address */
> - rte_cryptodev_create_unique_device_name(cryptodev_name,
> - sizeof(cryptodev_name), pci_dev);
> + rte_eal_pci_device_name(_dev->addr, cryptodev_name,
> + sizeof(cryptodev_name));
>
> cryptodev = rte_cryptodev_pmd_get_named_dev(cryptodev_name);
> if (cryptodev == NULL)
> diff --git a/lib/librte_eal/common/include/rte_pci.h
> b/lib/librte_eal/common/include/rte_pci.h
> index 3027adf..06508fa 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -82,6 +82,7 @@ extern "C" {
> #include
> #include
>
> +#include
> #include
>
> TAILQ_HEAD(pci_device_list, rte_pci_device); /**< PCI devices in D-linked Q.
> */
> @@ -95,6 +96,7 @@ const char *pci_get_sysfs_path(void);
>
> /** Formatting string for PCI device identifier: Ex: :00:01.0 */
> #define PCI_PRI_FMT "%.4" PRIx16 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
> +#define PCI_PRI_STR_SIZE sizeof(":XX:XX.X")
>
> /** Short formatting string, without domain, for PCI device: Ex: 00:01.0 */
> #define PCI_SHORT_PRI_FMT "%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
> @@ -308,6 +310,29 @@ eal_parse_pci_DomBDF(const char *input, struct
> rte_pci_addr *dev_addr)
> }
> #undef GET_PCIADDR_FIELD
>
> +/**
> + * Utility function to write a pci device name, this device name can later be
> + * used to retrieve the corresponding rte_pci_addr using above functions.
What about saying "using functions eal_parse_pci_*BDF"? The
specification "above" is quite uncertain...
> + *
> + * @param addr
> + * The PCI Bus-Device-Function address
> + * @param output
> + * The output buffer string
> + * @param size
> + * The output buffer size
> + * @return
> + * 0 on success, negative on error.
> + */
> +static inline void
> +rte_eal_pci_device_name(const struct rte_pci_addr *addr,
> + char *output, size_t size)
> +{
> + RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
> + RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
> + addr->domain, addr->bus,
> + addr->devid, addr->function) >= 0);
> +}
> +
> /* Compare two PCI device addresses. */
> /**
[...]
[dpdk-dev] [PATCH v6 16/17] ethdev: convert to eal hotplug
On Tue, 12 Jul 2016 11:31:21 +0530
Shreyansh Jain wrote:
> Remove bus logic from ethdev hotplug by using eal for this.
>
> Current api is preserved:
> - the last port that has been created is tracked to return it to the
> application when attaching,
> - the internal device name is reused when detaching.
>
> We can not get rid of ethdev hotplug yet since we still need some mechanism
> to inform applications of port creation/removal to substitute for ethdev
> hotplug api.
>
> dev_type field in struct rte_eth_dev and rte_eth_dev_allocate are kept as
> is, but this information is not needed anymore and is removed in the following
> commit.
>
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
> ---
> lib/librte_ether/rte_ethdev.c | 207
> +++---
> 1 file changed, 33 insertions(+), 174 deletions(-)
>
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index a667012..8d14fd7 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -72,6 +72,7 @@
> static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
> struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
> static struct rte_eth_dev_data *rte_eth_dev_data;
> +static uint8_t eth_dev_last_created_port;
> static uint8_t nb_ports;
>
[...]
> -
> /* attach the new device, then store port_id of the device */
> int
> rte_eth_dev_attach(const char *devargs, uint8_t *port_id)
> {
> - struct rte_pci_addr addr;
> int ret = -1;
> + int current = eth_dev_last_created_port;
> + char *name = NULL;
> + char *args = NULL;
>
> if ((devargs == NULL) || (port_id == NULL)) {
> ret = -EINVAL;
> goto err;
> }
>
> - if (eal_parse_pci_DomBDF(devargs, ) == 0) {
> - ret = rte_eth_dev_attach_pdev(, port_id);
> - if (ret < 0)
> - goto err;
> - } else {
> - ret = rte_eth_dev_attach_vdev(devargs, port_id);
> - if (ret < 0)
> - goto err;
> + /* parse devargs, then retrieve device name and args */
> + if (rte_eal_parse_devargs_str(devargs, , ))
> + goto err;
> +
> + ret = rte_eal_dev_attach(name, args);
> + if (ret < 0)
> + goto err;
> +
> + /* no point looking at eth_dev_last_created_port if no port exists */
I am not sure about this comment. What is "no point"?
Isn't this also a potential bug? (Like the one below.) How could it
happen there is no port after a successful attach?
> + if (!nb_ports) {
> + ret = -1;
> + goto err;
> + }
> + /* if nothing happened, there is a bug here, since some driver told us
> + * it did attach a device, but did not create a port */
> + if (current == eth_dev_last_created_port) {
> + ret = -1;
> + goto err;
Should we log this? Or call some kind panic?
> }
> + *port_id = eth_dev_last_created_port;
> + ret = 0;
>
> - return 0;
> err:
> - RTE_LOG(ERR, EAL, "Driver, cannot attach the device\n");
> + free(name);
> + free(args);
> return ret;
> }
>
> @@ -590,7 +464,6 @@ err:
> int
> rte_eth_dev_detach(uint8_t port_id, char *name)
> {
> - struct rte_pci_addr addr;
> int ret = -1;
>
> if (name == NULL) {
> @@ -598,33 +471,19 @@ rte_eth_dev_detach(uint8_t port_id, char *name)
> goto err;
> }
>
> - /* check whether the driver supports detach feature, or not */
> + /* FIXME: move this to eal, once device flags are relocated there */
> if (rte_eth_dev_is_detachable(port_id))
> goto err;
>
> - if (rte_eth_dev_get_device_type(port_id) == RTE_ETH_DEV_PCI) {
> - ret = rte_eth_dev_get_addr_by_port(port_id, );
> - if (ret < 0)
> - goto err;
> -
> - ret = rte_eth_dev_detach_pdev(port_id, );
> - if (ret < 0)
> - goto err;
> -
> - snprintf(name, RTE_ETH_NAME_MAX_LEN,
> - "%04x:%02x:%02x.%d",
> - addr.domain, addr.bus,
> - addr.devid, addr.function);
> - } else {
> - ret = rte_eth_dev_detach_vdev(port_id, name);
> - if (ret < 0)
> - goto err;
> - }
> + snprintf(name, sizeof(rte_eth_devices[port_id].data->name),
> + "%s", rte_eth_devices[port_id].data->name);
> + ret = rte_eal_dev_detach(name);
> + if (ret < 0)
> + goto err;
>
> return 0;
>
> err:
> - RTE_LOG(ERR, EAL, "Driver, cannot detach the device\n");
I'd be more specific about the failing device, we have its name.
> return ret;
> }
>
[dpdk-dev] [PATCH v6 15/17] eal: add hotplug operations for pci and vdev
On Tue, 12 Jul 2016 11:31:20 +0530
Shreyansh Jain wrote:
> Hotplug which deals with resources should come from the layer that already
> handles them, i.e. EAL.
>
> For both attach and detach operations, 'name' is used to select the bus
> that will handle the request.
>
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
> ---
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 2 ++
> lib/librte_eal/common/eal_common_dev.c | 47
> +
> lib/librte_eal/common/include/rte_dev.h | 25 +
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 ++
> 4 files changed, 76 insertions(+)
>
> diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> index 1852c4a..6f9324f 100644
> --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> @@ -159,5 +159,7 @@ DPDK_16.07 {
> rte_keepalive_mark_sleep;
> rte_keepalive_register_relay_callback;
> rte_thread_setname;
> + rte_eal_dev_attach;
> + rte_eal_dev_detach;
>
> } DPDK_16.04;
> diff --git a/lib/librte_eal/common/eal_common_dev.c
> b/lib/librte_eal/common/eal_common_dev.c
> index a8a4146..14c6cf1 100644
> --- a/lib/librte_eal/common/eal_common_dev.c
> +++ b/lib/librte_eal/common/eal_common_dev.c
> @@ -150,3 +150,50 @@ rte_eal_vdev_uninit(const char *name)
> RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
> return -EINVAL;
> }
> +
> +int rte_eal_dev_attach(const char *name, const char *devargs)
> +{
> + struct rte_pci_addr addr;
> + int ret = -1;
> +
> + if (name == NULL || devargs == NULL) {
> + RTE_LOG(ERR, EAL, "Invalid device arguments provided\n");
> + return ret;
> + }
> +
> + if (eal_parse_pci_DomBDF(name, ) == 0) {
> + if (rte_eal_pci_probe_one() < 0)
> + goto err;
> +
> + } else {
> + if (rte_eal_vdev_init(name, devargs))
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + RTE_LOG(ERR, EAL, "Driver cannot attach the device\n");
I think this log can be more specific. We have the name of the device.
It might be confusing to the user when the attach fails and there is
no simple way how to determine which one.
> + return ret;
> +}
> +
> +int rte_eal_dev_detach(const char *name)
> +{
> + struct rte_pci_addr addr;
> +
> + if (name == NULL)
> + goto err;
> +
> + if (eal_parse_pci_DomBDF(name, ) == 0) {
> + if (rte_eal_pci_detach() < 0)
> + goto err;
> + } else {
> + if (rte_eal_vdev_uninit(name))
> + goto err;
> + }
> + return 0;
> +
> +err:
> + RTE_LOG(ERR, EAL, "Driver cannot detach the device\n");
Same as for attach.
> + return -1;
> +}
> diff --git a/lib/librte_eal/common/include/rte_dev.h
> b/lib/librte_eal/common/include/rte_dev.h
> index 994650b..2f0579c 100644
> --- a/lib/librte_eal/common/include/rte_dev.h
> +++ b/lib/librte_eal/common/include/rte_dev.h
> @@ -178,6 +178,31 @@ int rte_eal_vdev_init(const char *name, const char
> *args);
> */
> int rte_eal_vdev_uninit(const char *name);
>
> +/**
> + * Attach a resource to a registered driver.
[dpdk-dev] [PATCH v6 17/17] ethdev: get rid of device type
On Tue, 12 Jul 2016 11:31:22 +0530
Shreyansh Jain wrote:
> Now that hotplug has been moved to eal, there is no reason to keep the device
> type in this layer.
>
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
> ---
> app/test/virtual_pmd.c| 2 +-
> drivers/net/af_packet/rte_eth_af_packet.c | 2 +-
> drivers/net/bonding/rte_eth_bond_api.c| 2 +-
> drivers/net/cxgbe/cxgbe_main.c| 2 +-
> drivers/net/mlx4/mlx4.c | 2 +-
> drivers/net/mlx5/mlx5.c | 2 +-
> drivers/net/mpipe/mpipe_tilegx.c | 2 +-
> drivers/net/null/rte_eth_null.c | 2 +-
> drivers/net/pcap/rte_eth_pcap.c | 2 +-
> drivers/net/ring/rte_eth_ring.c | 2 +-
> drivers/net/vhost/rte_eth_vhost.c | 2 +-
> drivers/net/virtio/virtio_user_ethdev.c | 2 +-
> drivers/net/xenvirt/rte_eth_xenvirt.c | 2 +-
> examples/ip_pipeline/init.c | 22 --
> lib/librte_ether/rte_ethdev.c | 5 ++---
> lib/librte_ether/rte_ethdev.h | 15 +--
> 16 files changed, 16 insertions(+), 52 deletions(-)
>
[...]
>
> -static int
> -app_link_is_virtual(struct app_link_params *p)
> -{
> - uint32_t pmd_id = p->pmd_id;
> - struct rte_eth_dev *dev = _eth_devices[pmd_id];
> -
> - if (dev->dev_type == RTE_ETH_DEV_VIRTUAL)
> - return 1;
> -
> - return 0;
> -}
> -
> void
> app_link_up_internal(struct app_params *app, struct app_link_params *cp)
> {
> uint32_t i;
> int status;
>
> - if (app_link_is_virtual(cp)) {
> - cp->state = 1;
> - return;
> - }
> -
> /* For each link, add filters for IP of current link */
> if (cp->ip != 0) {
> for (i = 0; i < app->n_links; i++) {
> @@ -736,11 +719,6 @@ app_link_down_internal(struct app_params *app, struct
> app_link_params *cp)
> uint32_t i;
> int status;
>
> - if (app_link_is_virtual(cp)) {
> - cp->state = 0;
> - return;
> - }
> -
> /* PMD link down */
I understand that app_link_is_virtual is useless. However, it changes
semantics. What is the behaviour of the app_link_up_internal after this
change?
> status = rte_eth_dev_set_link_down(cp->pmd_id);
> if (status < 0)
[...]
[dpdk-dev] [PATCH v6 05/17] eal: introduce init macros
On Thu, 14 Jul 2016 10:57:55 +0530
Shreyansh jain wrote:
> Hi Jan,
>
> On Wednesday 13 July 2016 11:04 PM, Jan Viktorin wrote:
> > On Wed, 13 Jul 2016 11:20:43 +0200
> > Jan Viktorin wrote:
> >
> >> Hello Shreyansh,
> >>
> >> On Tue, 12 Jul 2016 11:31:10 +0530
> >> Shreyansh Jain wrote:
> >>
> >>> Introduce a RTE_INIT macro used to mark an init function as a constructor.
> >>> Current eal macros have been converted to use this (no functional impact).
> >>> DRIVER_REGISTER_PCI is added as a helper for pci drivers.
> >>>
> >>> Suggested-by: Jan Viktorin
> >>> Signed-off-by: David Marchand
> >>> Signed-off-by: Shreyansh Jain
> >>> ---
> >>
> >> [...]
> >>
> >>> +#define RTE_INIT(func) \
> >>> +static void __attribute__((constructor, used)) func(void)
> >>> +
> >>> #ifdef __cplusplus
> >>> }
> >>> #endif
> >>> diff --git a/lib/librte_eal/common/include/rte_pci.h
> >>> b/lib/librte_eal/common/include/rte_pci.h
> >>> index fa74962..3027adf 100644
> >>> --- a/lib/librte_eal/common/include/rte_pci.h
> >>> +++ b/lib/librte_eal/common/include/rte_pci.h
> >>> @@ -470,6 +470,14 @@ void rte_eal_pci_dump(FILE *f);
> >>> */
> >>> void rte_eal_pci_register(struct rte_pci_driver *driver);
> >>>
> >>> +/** Helper for PCI device registeration from driver (eth, crypto)
> >>> instance */
> >>> +#define DRIVER_REGISTER_PCI(nm, drv) \
> >>> +RTE_INIT(pciinitfn_ ##nm); \
> >>> +static void pciinitfn_ ##nm(void) \
> >>> +{ \
> >>
> >> You are missing setting the name here like PMD_REGISTER_DRIVER does
> >> now. Or should I include it in my patch set?
> >>
> >>(drv).name = RTE_STR(nm);
>
> That is a miss from my side.
> I will publish v7 with this. You want this right away or should I wait a
> little while (more reviews, or any pending additions as per Thomas's notes)
> before publishing?
Please. The time is almost gone. 18/7/2016 is the release (according
to the roadmap)... I have to fix it in my patchset, otherwise it
does not build (after moving the .name from rte_pci_driver to
rte_driver).
>
> >
> > Moreover, it should accept the rte_pci_driver *, shouldn't it? Here, it
> > expects a wrapper around it (eth_driver)... I now, my SoC patches were
> > supposing the some... but I think it is wrong.
> >
> > The original David's patch set contains calls like this:
> >
> > RTE_EAL_PCI_REGISTER(bnx2xvf, rte_bnx2xvf_pmd.pci_drv);
> >
> > So, I think, we should go the original way.
>
> I have a slightly different opinion of the above.
> IMO, aim of the helpers is to hide the PCI details and continue to make
> driver consider itself as a generic ETH driver. In that case, dereferencing
> pci_drv would be done by macro.
In this case, I'd prefer to see DRIVER_REGISTER_PCI_ETH.
At first, this was also my way of thinking. But I've changed my mind. I
find it to be a bit overdesigned.
>
> Also, considering that in future pci_drv would also have soc_drv, the helpers
> can effectively hide the intra-structure naming of these. It would help when
> more such device types (would there be?) are introduced - in which case,
> driver framework has a consistent coding convention.
Hide? I am afraid, I don't understand clearly what you mean.
>
> But, I am ok switching back to David's way as well - I don't have any strong
> argument against that.
I'd like to preserve the clear semantics. That is DRIVER_REGISTER_PCI
-> give a pci device.
Has anybody a different opinion? David? Thomas?
>
> >
> > Jan
> >
> >>
> >>> + rte_eal_pci_register(_drv); \
> >>> +}
> >>> +
> >>> /**
> >>> * Unregister a PCI driver.
> >>> *
> [...]
>
> -
> Shreyansh
>
--
Jan ViktorinE-mail: Viktorin at RehiveTech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH] virtio: fix missing curly braces
On Wed, 13 Jul 2016 11:27:18 +0200
Maxime Coquelin wrote:
> Hi Jan,
>
> On 07/13/2016 11:24 AM, Jan Viktorin wrote:
> > GCC 6 is complaining and seems to be correct here.
> >
> > virtio_user_ethdev.c:345:2: error:
> > this ?if? clause does not guard... [-Werror=misleading-indentation]
> >if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PATH) == 1)
> >^~
> >
> > virtio_user_ethdev.c:348:3: note:
> > ...this statement, but the latter is misleadingly indented
> > as if it is guarded by the ?if?
> > if (ret < 0) {
> >
> > Fixes: 404bd6bfe360 ("net/virtio-user: fix return value not checked")
> > Signed-off-by: Jan Viktorin
> > ---
> >
> I already fixed it yesterday:
> http://dpdk.org/dev/patchwork/patch/14780/
Sorry, I didn't find it quickly. My fault. Thanks.
Jan
>
> Thanks,
> Maxime
[dpdk-dev] [PATCH] virtio: fix missing curly braces
On Wed, 13 Jul 2016 11:27:18 +0200
Maxime Coquelin wrote:
> Hi Jan,
>
> On 07/13/2016 11:24 AM, Jan Viktorin wrote:
> > GCC 6 is complaining and seems to be correct here.
> >
> > virtio_user_ethdev.c:345:2: error:
> > this ?if? clause does not guard... [-Werror=misleading-indentation]
> >if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PATH) == 1)
> >^~
> >
> > virtio_user_ethdev.c:348:3: note:
> > ...this statement, but the latter is misleadingly indented
> > as if it is guarded by the ?if?
> > if (ret < 0) {
> >
> > Fixes: 404bd6bfe360 ("net/virtio-user: fix return value not checked")
> > Signed-off-by: Jan Viktorin
> > ---
> >
> I already fixed it yesterday:
> http://dpdk.org/dev/patchwork/patch/14780/
Sorry, I didn't find it quickly. My fault. Thanks.
Jan
>
> Thanks,
> Maxime
--
Jan ViktorinE-mail: Viktorin at RehiveTech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v6 05/17] eal: introduce init macros
On Wed, 13 Jul 2016 11:20:43 +0200
Jan Viktorin wrote:
> Hello Shreyansh,
>
> On Tue, 12 Jul 2016 11:31:10 +0530
> Shreyansh Jain wrote:
>
> > Introduce a RTE_INIT macro used to mark an init function as a constructor.
> > Current eal macros have been converted to use this (no functional impact).
> > DRIVER_REGISTER_PCI is added as a helper for pci drivers.
> >
> > Suggested-by: Jan Viktorin
> > Signed-off-by: David Marchand
> > Signed-off-by: Shreyansh Jain
> > ---
>
> [...]
>
> > +#define RTE_INIT(func) \
> > +static void __attribute__((constructor, used)) func(void)
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/librte_eal/common/include/rte_pci.h
> > b/lib/librte_eal/common/include/rte_pci.h
> > index fa74962..3027adf 100644
> > --- a/lib/librte_eal/common/include/rte_pci.h
> > +++ b/lib/librte_eal/common/include/rte_pci.h
> > @@ -470,6 +470,14 @@ void rte_eal_pci_dump(FILE *f);
> > */
> > void rte_eal_pci_register(struct rte_pci_driver *driver);
> >
> > +/** Helper for PCI device registeration from driver (eth, crypto) instance
> > */
> > +#define DRIVER_REGISTER_PCI(nm, drv) \
> > +RTE_INIT(pciinitfn_ ##nm); \
> > +static void pciinitfn_ ##nm(void) \
> > +{ \
>
> You are missing setting the name here like PMD_REGISTER_DRIVER does
> now. Or should I include it in my patch set?
>
> (drv).name = RTE_STR(nm);
Moreover, it should accept the rte_pci_driver *, shouldn't it? Here, it
expects a wrapper around it (eth_driver)... I now, my SoC patches were
supposing the some... but I think it is wrong.
The original David's patch set contains calls like this:
RTE_EAL_PCI_REGISTER(bnx2xvf, rte_bnx2xvf_pmd.pci_drv);
So, I think, we should go the original way.
Jan
>
> > + rte_eal_pci_register(_drv); \
> > +}
> > +
> > /**
> > * Unregister a PCI driver.
> > *
> > diff --git a/lib/librte_eal/common/include/rte_tailq.h
> > b/lib/librte_eal/common/include/rte_tailq.h
> > index 4a686e6..71ed3bb 100644
> > --- a/lib/librte_eal/common/include/rte_tailq.h
> > +++ b/lib/librte_eal/common/include/rte_tailq.h
> > @@ -148,8 +148,8 @@ struct rte_tailq_head *rte_eal_tailq_lookup(const char
> > *name);
> > int rte_eal_tailq_register(struct rte_tailq_elem *t);
> >
> > #define EAL_REGISTER_TAILQ(t) \
> > -void tailqinitfn_ ##t(void); \
> > -void __attribute__((constructor, used)) tailqinitfn_ ##t(void) \
> > +RTE_INIT(tailqinitfn_ ##t); \
> > +static void tailqinitfn_ ##t(void) \
> > { \
> > if (rte_eal_tailq_register() < 0) \
> > rte_panic("Cannot initialize tailq: %s\n", t.name); \
>
>
>
--
Jan ViktorinE-mail: Viktorin at RehiveTech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH] virtio: fix missing curly braces
GCC 6 is complaining and seems to be correct here.
virtio_user_ethdev.c:345:2: error:
this ?if? clause does not guard... [-Werror=misleading-indentation]
if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PATH) == 1)
^~
virtio_user_ethdev.c:348:3: note:
...this statement, but the latter is misleadingly indented
as if it is guarded by the ?if?
if (ret < 0) {
Fixes: 404bd6bfe360 ("net/virtio-user: fix return value not checked")
Signed-off-by: Jan Viktorin
---
drivers/net/virtio/virtio_user_ethdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio/virtio_user_ethdev.c
b/drivers/net/virtio/virtio_user_ethdev.c
index 17d5848..1b903f3 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -342,7 +342,7 @@ virtio_user_pmd_devinit(const char *name, const char
*params)
goto end;
}
- if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PATH) == 1)
+ if (rte_kvargs_count(kvlist, VIRTIO_USER_ARG_PATH) == 1) {
ret = rte_kvargs_process(kvlist, VIRTIO_USER_ARG_PATH,
_string_arg, );
if (ret < 0) {
@@ -350,7 +350,7 @@ virtio_user_pmd_devinit(const char *name, const char
*params)
VIRTIO_USER_ARG_PATH);
goto end;
}
- else {
+ } else {
PMD_INIT_LOG(ERR, "arg %s is mandatory for virtio-user\n",
VIRTIO_USER_ARG_QUEUE_SIZE);
goto end;
--
2.9.0
[dpdk-dev] [PATCH v6 05/17] eal: introduce init macros
Hello Shreyansh,
On Tue, 12 Jul 2016 11:31:10 +0530
Shreyansh Jain wrote:
> Introduce a RTE_INIT macro used to mark an init function as a constructor.
> Current eal macros have been converted to use this (no functional impact).
> DRIVER_REGISTER_PCI is added as a helper for pci drivers.
>
> Suggested-by: Jan Viktorin
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
> ---
[...]
> +#define RTE_INIT(func) \
> +static void __attribute__((constructor, used)) func(void)
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_eal/common/include/rte_pci.h
> b/lib/librte_eal/common/include/rte_pci.h
> index fa74962..3027adf 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -470,6 +470,14 @@ void rte_eal_pci_dump(FILE *f);
> */
> void rte_eal_pci_register(struct rte_pci_driver *driver);
>
> +/** Helper for PCI device registeration from driver (eth, crypto) instance */
> +#define DRIVER_REGISTER_PCI(nm, drv) \
> +RTE_INIT(pciinitfn_ ##nm); \
> +static void pciinitfn_ ##nm(void) \
> +{ \
You are missing setting the name here like PMD_REGISTER_DRIVER does
now. Or should I include it in my patch set?
(drv).name = RTE_STR(nm);
> + rte_eal_pci_register(_drv); \
> +}
> +
> /**
> * Unregister a PCI driver.
> *
> diff --git a/lib/librte_eal/common/include/rte_tailq.h
> b/lib/librte_eal/common/include/rte_tailq.h
> index 4a686e6..71ed3bb 100644
> --- a/lib/librte_eal/common/include/rte_tailq.h
> +++ b/lib/librte_eal/common/include/rte_tailq.h
> @@ -148,8 +148,8 @@ struct rte_tailq_head *rte_eal_tailq_lookup(const char
> *name);
> int rte_eal_tailq_register(struct rte_tailq_elem *t);
>
> #define EAL_REGISTER_TAILQ(t) \
> -void tailqinitfn_ ##t(void); \
> -void __attribute__((constructor, used)) tailqinitfn_ ##t(void) \
> +RTE_INIT(tailqinitfn_ ##t); \
> +static void tailqinitfn_ ##t(void) \
> { \
> if (rte_eal_tailq_register() < 0) \
> rte_panic("Cannot initialize tailq: %s\n", t.name); \
--
Jan ViktorinE-mail: Viktorin at RehiveTech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v1 28/28] ether: support SoC device/driver
On Tue, 12 Jul 2016 14:15:17 +0530 Shreyansh jain wrote: > Hi Jan, > > On Monday 04 July 2016 08:06 PM, Jan Viktorin wrote: > > On Mon, 4 Jul 2016 19:57:18 +0530 > > Shreyansh jain wrote: > > > > [...] > > > >>>>> @@ -1431,7 +1524,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct > >>>>> rte_eth_dev_info *dev_info) > >>>>> > >>>>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get); > >>>>> (*dev->dev_ops->dev_infos_get)(dev, dev_info); > >>>>> - dev_info->pci_dev = dev->pci_dev; > >>>>> + dev_info->soc_dev = dev->soc_dev; > >>>> > >>>> I think both the members, pci_dev and soc_dev, should be updated by this > >>>> call. > >>>> Is there some specific reason why soc_dev is the only one which is > >>>> getting updated? > >>> > >>> Yes, looks like a mistake. Thanks! And sorry for delayed reply. > >> > >> No problems - thanks for confirmation. > >> I have gone through almost complete series and as and when you rebase it, > >> it would have my ACK. > > > > OK, thanks. That's what I am playing with right now. I've rebased on v3 of > > this patch. There will > > be some more tests in my v2. > > > >> rte_driver patchset which I sent last are broken - I will publish an > >> updated version very soon. > > > > I am surprised that you've changed the args to RTE_EAL_PCI_REGISTER... Are > > you sure about this step? > > I wrote that I'll change it myself for v2 for SoC to accept name and > > pointer as it was originally for PCI... > > I have sent across a v6 of the rte_device/driver change set. > Can you see if that is in-line with your expectations as well as the series > [1] posted by you recently? > I was making changes for vdev but for now I have ignored them as your series > already includes those changes. > > I used your patches and based them over the v6 rte_device patchset - besides > some minor conflicts, its seems to merge fine. > > [1] http://dpdk.org/ml/archives/dev/2016-July/043645.html I will check it as soon as possible. Thanks. Jan > > > > > Jan > > > > - > Shreyansh > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v1 01/15] eal: extract vdev infra
On Mon, 11 Jul 2016 18:59:48 +0530
Shreyansh jain wrote:
> Hi Jan,
>
> Some comments.
>
> On Saturday 09 July 2016 12:39 AM, Jan Viktorin wrote:
> > Move all PMD_VDEV-specific code into a separate module and header
> > file to not polute the generic code anymore. There is now a list
> > of virtual devices available.
> >
> > The rte_vdev_driver integrates the original rte_driver inside
> > (C inheritance). The rte_driver will be however change in the
> > future to serve as a common base for all other types of drivers.
> >
> > The existing PMDs (PMD_VDEV) are to be modified later (there is
> > no change for them at the moment).
> >
> > There is however a inconsistency. The functions rte_eal_vdev_init
> > and rte_eal_vdev_uninit are still placed in the rte_dev.h (instead
> > of the rte_vdev.h).
> >
> > Signed-off-by: Jan Viktorin
> > ---
[...]
> > +
> > +/* unregister a driver */
> > +void
> > +rte_eal_vdrv_unregister(struct rte_vdev_driver *driver)
> > +{
> > + TAILQ_REMOVE(_driver_list, driver, next);
> > +}
> > +
> > +int
> > +rte_eal_vdev_init(const char *name, const char *args)
> > +{
> > + struct rte_vdev_driver *driver;
> > +
> > + if (name == NULL)
> > + return -EINVAL;
> > +
> > + TAILQ_FOREACH(driver, _driver_list, next) {
> > + if (driver->driver.type != PMD_VDEV)
> > + continue;
>
> Now that two separate lists for vdev and pdev exist, we don't need this check
> anymore.
> In fact, PMD_VDEV might not even exist.
Solved already in the next 2 patches.
>
> > +
> > + /*
> > +* search a driver prefix in virtual device name.
> > +* For example, if the driver is pcap PMD, driver->name
> > +* will be "eth_pcap", but "name" will be "eth_pcapN".
> > +* So use strncmp to compare.
> > +*/
> > + if (!strncmp(driver->driver.name, name,
> > strlen(driver->driver.name)))
> > + return driver->driver.init(name, args);
> > + }
> > +
> > + RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
> > + return -EINVAL;
> > +}
> > +
> > +int
> > +rte_eal_vdev_uninit(const char *name)
> > +{
> > + struct rte_vdev_driver *driver;
> > +
> > + if (name == NULL)
> > + return -EINVAL;
> > +
> > + TAILQ_FOREACH(driver, _driver_list, next) {
> > + if (driver->driver.type != PMD_VDEV)
> > + continue;
>
> Same as above, redundant check.
Solved already in the next 2 patches.
>
> > +
> > + /*
> > +* search a driver prefix in virtual device name.
> > +* For example, if the driver is pcap PMD, driver->name
> > +* will be "eth_pcap", but "name" will be "eth_pcapN".
> > +* So use strncmp to compare.
> > +*/
> > + if (!strncmp(driver->driver.name, name,
> > strlen(driver->driver.name)))
> > + return driver->driver.uninit(name);
> > + }
> > +
> > + RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
> > + return -EINVAL;
> > +}
> > diff --git a/lib/librte_eal/common/include/rte_dev.h
> > b/lib/librte_eal/common/include/rte_dev.h
> > index b1c0520..2aeb752 100644
> > --- a/lib/librte_eal/common/include/rte_dev.h
> > +++ b/lib/librte_eal/common/include/rte_dev.h
> > @@ -210,6 +210,7 @@ static void devinitfn_ ##d(void)\
> > rte_eal_driver_register();\
> > }
> >
> > +
>
> Probably a stray newline.
Will fix.
>
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/librte_eal/common/include/rte_vdev.h
> > b/lib/librte_eal/common/include/rte_vdev.h
> > new file mode 100644
> > index 000..523bd92
> > --- /dev/null
> > +++ b/lib/librte_eal/common/include/rte_vdev.h
> > @@ -0,0 +1,83 @@
[...]
> > +/**
> > + * Unregister a virtual device driver.
> > + *
> > + * @param driver
> > + * A pointer to a rte_vdev_driver structure describing the driver
> > + * to be unregistered.
> > + */
> > +void rte_eal_vdrv_unregister(struct rte_vdev_driver *driver);
> > +
> > +#define RTE_EAL_VDRV_REGISTER(d)\
>
> In the recent commits, I noticed that macros have taken the (name, driver)
> format.
&
[dpdk-dev] [PATCH v1 15/15] eal/pci: insert rte_device on scan
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 6f1a28a..ab08a16 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -390,6 +390,7 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t
bus,
/* device is valid, add in list (sorted) */
if (TAILQ_EMPTY(_device_list)) {
+ rte_eal_device_insert(>device);
TAILQ_INSERT_TAIL(_device_list, dev, next);
} else {
struct rte_pci_device *dev2;
@@ -402,6 +403,7 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t
bus,
if (ret < 0) {
TAILQ_INSERT_BEFORE(dev2, dev, next);
+ rte_eal_device_insert(>device);
} else { /* already registered */
dev2->kdrv = dev->kdrv;
dev2->max_vfs = dev->max_vfs;
@@ -411,6 +413,7 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t
bus,
}
return 0;
}
+ rte_eal_device_insert(>device);
TAILQ_INSERT_TAIL(_device_list, dev, next);
}
--
2.9.0
[dpdk-dev] [PATCH v1 14/15] eal/pci: inherit rte_device by rte_pci_device
Signed-off-by: Jan Viktorin
---
app/test/virtual_pmd.c | 4 ++--
drivers/net/fm10k/fm10k_ethdev.c| 6 +++---
drivers/net/virtio/virtio_pci.c | 2 +-
lib/librte_cryptodev/rte_cryptodev.c| 2 +-
lib/librte_eal/common/eal_common_pci.c | 14 +++---
lib/librte_eal/common/include/rte_pci.h | 4 +---
lib/librte_eal/linuxapp/eal/eal_pci.c | 4 ++--
lib/librte_ether/rte_ethdev.c | 14 +-
8 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index 56eeb99..4831113 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -585,7 +585,7 @@ virtual_ethdev_create(const char *name, struct ether_addr
*mac_addr,
if (eth_dev == NULL)
goto err;
- pci_dev->numa_node = socket_id;
+ pci_dev->device.numa_node = socket_id;
pci_drv->driver.name = virtual_ethdev_driver_name;
pci_drv->id_table = id_table;
@@ -626,7 +626,7 @@ virtual_ethdev_create(const char *name, struct ether_addr
*mac_addr,
eth_dev->dev_ops = _private->dev_ops;
eth_dev->pci_dev = pci_dev;
- eth_dev->pci_dev->driver = _drv->pci_drv;
+ eth_dev->pci_dev->device.driver = _drv->pci_drv.driver;
eth_dev->rx_pkt_burst = virtual_ethdev_rx_burst_success;
eth_dev->tx_pkt_burst = virtual_ethdev_tx_burst_success;
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 4ffa66c..4230a75 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -675,7 +675,7 @@ fm10k_dev_tx_init(struct rte_eth_dev *dev)
/* Enable use of FTAG bit in TX descriptor, PFVTCTL
* register is read-only for VF.
*/
- if (fm10k_check_ftag(dev->pci_dev->devargs)) {
+ if (fm10k_check_ftag(dev->pci_dev->device.devargs)) {
if (hw->mac.type == fm10k_mac_pf) {
FM10K_WRITE_REG(hw, FM10K_PFVTCTL(i),
FM10K_PFVTCTL_FTAG_DESC_ENABLE);
@@ -2734,7 +2734,7 @@ fm10k_set_tx_function(struct rte_eth_dev *dev)
int use_sse = 1;
uint16_t tx_ftag_en = 0;
- if (fm10k_check_ftag(dev->pci_dev->devargs))
+ if (fm10k_check_ftag(dev->pci_dev->device.devargs))
tx_ftag_en = 1;
for (i = 0; i < dev->data->nb_tx_queues; i++) {
@@ -2767,7 +2767,7 @@ fm10k_set_rx_function(struct rte_eth_dev *dev)
uint16_t i, rx_using_sse;
uint16_t rx_ftag_en = 0;
- if (fm10k_check_ftag(dev->pci_dev->devargs))
+ if (fm10k_check_ftag(dev->pci_dev->device.devargs))
rx_ftag_en = 1;
/* In order to allow Vector Rx there are a few configuration
diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 9c9a3dd..6fbfa39 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -719,7 +719,7 @@ vtpci_init(struct rte_pci_device *dev, struct virtio_hw *hw,
PMD_INIT_LOG(INFO, "trying with legacy virtio pci.");
if (legacy_virtio_resource_init(dev, hw, dev_flags) < 0) {
if (dev->kdrv == RTE_KDRV_UNKNOWN &&
- dev->devargs->type != RTE_DEVTYPE_WHITELISTED_PCI) {
+ dev->device.devargs->type != RTE_DEVTYPE_WHITELISTED_PCI) {
PMD_INIT_LOG(INFO,
"skip kernel managed virtio device.");
return 1;
diff --git a/lib/librte_cryptodev/rte_cryptodev.c
b/lib/librte_cryptodev/rte_cryptodev.c
index afb13d7..d2a2a60 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -401,7 +401,7 @@ rte_cryptodev_pci_remove(struct rte_pci_device *pci_dev)
if (cryptodev == NULL)
return -ENODEV;
- cryptodrv = (const struct rte_cryptodev_driver *)pci_dev->driver;
+ cryptodrv = (const struct rte_cryptodev_driver
*)to_pci_driver(pci_dev->device.driver);
if (cryptodrv == NULL)
return -ENODEV;
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 144479e..66ceba6 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -183,11 +183,11 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr,
struct rte_pci_device *d
RTE_LOG(INFO, EAL, "PCI device "PCI_PRI_FMT" on NUMA socket
%i\n",
loc->domain, loc->bus, loc->devid,
loc->function,
- dev->numa_node);
+ dev->device.numa_node);
/* no initialization when blacklisted, return wi
[dpdk-dev] [PATCH v1 13/15] eal: introduce rte_device
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_dev.c | 13 +
lib/librte_eal/common/include/rte_dev.h | 31 +++
2 files changed, 44 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common/eal_common_dev.c
index f4c880c..2c2a1bd 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -48,6 +48,9 @@
/** Global list of device drivers. */
static struct rte_driver_list dev_driver_list =
TAILQ_HEAD_INITIALIZER(dev_driver_list);
+/** Global list of device drivers. */
+static struct rte_device_list dev_device_list =
+ TAILQ_HEAD_INITIALIZER(dev_device_list);
/* register a driver */
void
@@ -63,6 +66,16 @@ rte_eal_driver_unregister(struct rte_driver *driver)
TAILQ_REMOVE(_driver_list, driver, next);
}
+void rte_eal_device_insert(struct rte_device *dev)
+{
+ TAILQ_INSERT_TAIL(_device_list, dev, next);
+}
+
+void rte_eal_device_remove(struct rte_device *dev)
+{
+ TAILQ_REMOVE(_device_list, dev, next);
+}
+
int
rte_eal_dev_init(void)
{
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index 2a0d326..d767012 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -112,6 +112,37 @@ struct rte_mem_resource {
/** Double linked list of device drivers. */
TAILQ_HEAD(rte_driver_list, rte_driver);
+/** Double linked list of devices. */
+TAILQ_HEAD(rte_device_list, rte_device);
+
+/* Forward declaration */
+struct rte_driver;
+
+/**
+ * A structure describing a generic device.
+ */
+struct rte_device {
+ TAILQ_ENTRY(rte_device) next; /**< Next device */
+ struct rte_driver *driver;/**< Associated driver */
+ int numa_node;/**< NUMA node connection */
+ struct rte_devargs *devargs; /**< Device user arguments */
+};
+
+/**
+ * Insert a device detected by a bus scanning.
+ *
+ * @param dev
+ * A pointer to a rte_device structure describing the detected device.
+ */
+void rte_eal_device_insert(struct rte_device *dev);
+
+/**
+ * Remove a device (e.g. when being unplugged).
+ *
+ * @param dev
+ * A pointer to a rte_device structure describing the device to be removed.
+ */
+void rte_eal_device_remove(struct rte_device *dev);
/**
* A structure describing a device driver.
--
2.9.0
[dpdk-dev] [PATCH v1 12/15] eal: call rte_eal_driver_register
To register both vdev and pci drivers into the list of all rte_driver,
we have to call rte_eal_driver_register explicitly.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_pci.c | 2 ++
lib/librte_eal/common/eal_common_vdev.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 3bcb059..144479e 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -468,11 +468,13 @@ void
rte_eal_pci_register(struct rte_pci_driver *driver)
{
TAILQ_INSERT_TAIL(_driver_list, driver, next);
+ rte_eal_driver_register(>driver);
}
/* unregister a driver */
void
rte_eal_pci_unregister(struct rte_pci_driver *driver)
{
+ rte_eal_driver_unregister(>driver);
TAILQ_REMOVE(_driver_list, driver, next);
}
diff --git a/lib/librte_eal/common/eal_common_vdev.c
b/lib/librte_eal/common/eal_common_vdev.c
index 7e7ddd1..389db3e 100644
--- a/lib/librte_eal/common/eal_common_vdev.c
+++ b/lib/librte_eal/common/eal_common_vdev.c
@@ -42,12 +42,14 @@ void
rte_eal_vdrv_register(struct rte_vdev_driver *driver)
{
TAILQ_INSERT_TAIL(_driver_list, driver, next);
+ rte_eal_driver_register(>driver);
}
/* unregister a driver */
void
rte_eal_vdrv_unregister(struct rte_vdev_driver *driver)
{
+ rte_eal_driver_unregister(>driver);
TAILQ_REMOVE(_driver_list, driver, next);
}
--
2.9.0
[dpdk-dev] [PATCH v1 11/15] eal/pci: inherit rte_driver by rte_pci_driver
Signed-off-by: Jan Viktorin
---
app/test/test_pci.c | 10 +++---
app/test/virtual_pmd.c | 2 +-
drivers/crypto/qat/rte_qat_cryptodev.c | 4 +++-
drivers/net/bnx2x/bnx2x_ethdev.c| 8 ++--
drivers/net/cxgbe/cxgbe_ethdev.c| 4 +++-
drivers/net/cxgbe/sge.c | 6 +++---
drivers/net/e1000/em_ethdev.c | 4 +++-
drivers/net/e1000/igb_ethdev.c | 8 ++--
drivers/net/ena/ena_ethdev.c| 4 +++-
drivers/net/enic/enic_ethdev.c | 4 +++-
drivers/net/fm10k/fm10k_ethdev.c| 4 +++-
drivers/net/i40e/i40e_ethdev.c | 4 +++-
drivers/net/i40e/i40e_ethdev_vf.c | 4 +++-
drivers/net/i40e/i40e_fdir.c| 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c| 8 ++--
drivers/net/mlx4/mlx4.c | 4 +++-
drivers/net/mlx5/mlx5.c | 4 +++-
drivers/net/nfp/nfp_net.c | 4 +++-
drivers/net/qede/qede_ethdev.c | 4
drivers/net/szedata2/rte_eth_szedata2.c | 4 +++-
drivers/net/virtio/virtio_ethdev.c | 6 --
drivers/net/vmxnet3/vmxnet3_ethdev.c| 7 +--
drivers/net/vmxnet3/vmxnet3_rxtx.c | 2 +-
lib/librte_cryptodev/rte_cryptodev.c| 4 ++--
lib/librte_eal/common/eal_common_pci.c | 4 ++--
lib/librte_eal/common/include/rte_pci.h | 4 +++-
lib/librte_ether/rte_ethdev.c | 4 ++--
27 files changed, 89 insertions(+), 38 deletions(-)
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 354a0ad..9be08f9 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -78,14 +78,18 @@ struct rte_pci_id my_driver_id2[] = {
};
struct rte_pci_driver my_driver = {
- .name = "test_driver",
+ .driver = {
+ .name = "test_driver",
+ },
.devinit = my_driver_init,
.id_table = my_driver_id,
.drv_flags = 0,
};
struct rte_pci_driver my_driver2 = {
- .name = "test_driver2",
+ .driver = {
+ .name = "test_driver2",
+ },
.devinit = my_driver_init,
.id_table = my_driver_id2,
.drv_flags = 0,
@@ -95,7 +99,7 @@ static int
my_driver_init(__attribute__((unused)) struct rte_pci_driver *dr,
struct rte_pci_device *dev)
{
- printf("My driver init called in %s\n", dr->name);
+ printf("My driver init called in %s\n", dr->driver.name);
printf("%x:%x:%x.%d", dev->addr.domain, dev->addr.bus,
dev->addr.devid, dev->addr.function);
printf(" - vendor:%x device:%x\n", dev->id.vendor_id,
dev->id.device_id);
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index 8a1f0d0..56eeb99 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -586,7 +586,7 @@ virtual_ethdev_create(const char *name, struct ether_addr
*mac_addr,
goto err;
pci_dev->numa_node = socket_id;
- pci_drv->name = virtual_ethdev_driver_name;
+ pci_drv->driver.name = virtual_ethdev_driver_name;
pci_drv->id_table = id_table;
if (isr_support)
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c
b/drivers/crypto/qat/rte_qat_cryptodev.c
index 970970a..fab8bd8 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -114,7 +114,9 @@ crypto_qat_dev_init(__attribute__((unused)) struct
rte_cryptodev_driver *crypto_
static struct rte_cryptodev_driver rte_qat_pmd = {
.pci_drv = {
- .name = "rte_qat_pmd",
+ .driver = {
+ .name = "rte_qat_pmd",
+ },
.id_table = pci_id_qat_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
.devinit = rte_cryptodev_pci_probe,
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 5ab3c75..062a93f 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -503,7 +503,9 @@ eth_bnx2xvf_dev_init(struct rte_eth_dev *eth_dev)
static struct eth_driver rte_bnx2x_pmd = {
.pci_drv = {
- .name = "rte_bnx2x_pmd",
+ .driver = {
+ .name = "rte_bnx2x_pmd",
+ },
.id_table = pci_id_bnx2x_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING | RTE_PCI_DRV_INTR_LSC,
.devinit = rte_eth_dev_pci_probe,
@@ -520,7 +522,9 @@ RTE_EAL_PCI_REGISTER(rte_bnx2x_pmd);
*/
static struct eth_driver rte_bnx2xvf_pmd = {
.pci_drv = {
- .name = "rte_bnx2xvf_pmd",
+ .driver = {
+ .name = "rte_bnx2xvf_pmd",
+ },
.id_table = pci_id_bnx2xvf_map,
.drv_flags = RTE_PCI_DRV_NEED_MAPPING,
.devinit = rte_eth_de
[dpdk-dev] [PATCH v1 10/15] eal: rename and move rte_pci_resource
There is no need to have a custom memory resource representation for
each infrastructure (PCI, ...) as it would always have the same members.
Signed-off-by: Jan Viktorin
---
drivers/net/szedata2/rte_eth_szedata2.c | 4 ++--
lib/librte_eal/common/include/rte_dev.h | 9 +
lib/librte_eal/common/include/rte_pci.h | 11 +--
lib/librte_eal/linuxapp/eal/eal_ivshmem.c | 2 +-
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/szedata2/rte_eth_szedata2.c
b/drivers/net/szedata2/rte_eth_szedata2.c
index 6815dbb..d925bc6 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1416,7 +1416,7 @@ rte_szedata2_eth_dev_init(struct rte_eth_dev *dev)
int ret;
uint32_t szedata2_index;
struct rte_pci_addr *pci_addr = >pci_dev->addr;
- struct rte_pci_resource *pci_rsc =
+ struct rte_mem_resource *pci_rsc =
>pci_dev->mem_resource[PCI_RESOURCE_NUMBER];
char rsc_filename[PATH_MAX];
void *pci_resource_ptr = NULL;
@@ -1473,7 +1473,7 @@ rte_szedata2_eth_dev_init(struct rte_eth_dev *dev)
rte_eth_copy_pci_info(dev, dev->pci_dev);
- /* mmap pci resource0 file to rte_pci_resource structure */
+ /* mmap pci resource0 file to rte_mem_resource structure */
if (dev->pci_dev->mem_resource[PCI_RESOURCE_NUMBER].phys_addr ==
0) {
RTE_LOG(ERR, PMD, "Missing resource%u file\n",
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index 225257e..2a0d326 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -100,6 +100,15 @@ rte_pmd_debug_trace(const char *func_name, const char
*fmt, ...)
} \
} while (0)
+/**
+ * A generic memory resource representation.
+ */
+struct rte_mem_resource {
+ uint64_t phys_addr; /**< Physical address, 0 if not resource. */
+ uint64_t len; /**< Length of the resource. */
+ void *addr; /**< Virtual address, NULL when not mapped. */
+};
+
/** Double linked list of device drivers. */
TAILQ_HEAD(rte_driver_list, rte_driver);
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index ec77cbc..950ea89 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -111,15 +111,6 @@ const char *pci_get_sysfs_path(void);
/** Default sysfs path for PCI device search. */
#define SYSFS_PCI_DEVICES "/sys/bus/pci/devices"
-/**
- * A structure describing a PCI resource.
- */
-struct rte_pci_resource {
- uint64_t phys_addr; /**< Physical address, 0 if no resource. */
- uint64_t len; /**< Length of the resource. */
- void *addr; /**< Virtual address, NULL when not mapped. */
-};
-
/** Maximum number of PCI resources. */
#define PCI_MAX_RESOURCE 6
@@ -163,7 +154,7 @@ struct rte_pci_device {
TAILQ_ENTRY(rte_pci_device) next; /**< Next probed PCI device. */
struct rte_pci_addr addr; /**< PCI location. */
struct rte_pci_id id; /**< PCI ID. */
- struct rte_pci_resource mem_resource[PCI_MAX_RESOURCE]; /**< PCI
Memory Resource */
+ struct rte_mem_resource mem_resource[PCI_MAX_RESOURCE]; /**< PCI
Memory Resource */
struct rte_intr_handle intr_handle; /**< Interrupt handle */
struct rte_pci_driver *driver; /**< Associated driver */
uint16_t max_vfs; /**< sriov enable if not zero */
diff --git a/lib/librte_eal/linuxapp/eal/eal_ivshmem.c
b/lib/librte_eal/linuxapp/eal/eal_ivshmem.c
index 67b3caf..20f9413 100644
--- a/lib/librte_eal/linuxapp/eal/eal_ivshmem.c
+++ b/lib/librte_eal/linuxapp/eal/eal_ivshmem.c
@@ -834,7 +834,7 @@ rte_eal_ivshmem_obj_init(void)
int rte_eal_ivshmem_init(void)
{
struct rte_pci_device * dev;
- struct rte_pci_resource * res;
+ struct rte_mem_resource * res;
int fd, ret;
char path[PATH_MAX];
--
2.9.0
[dpdk-dev] [PATCH v1 08/15] eal: define macro container_of
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/include/rte_common.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_common.h
b/lib/librte_eal/common/include/rte_common.h
index 332f2a4..a9b6792 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -322,6 +322,22 @@ rte_bsf32(uint32_t v)
#define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)
#endif
+/**
+ * Return pointer to the wrapping struct instance.
+ * Example:
+ *
+ * struct wrapper {
+ * ...
+ * struct child c;
+ * ...
+ * };
+ *
+ * struct child *x = obtain(...);
+ * struct wrapper *w = container_of(x, struct wrapper, c);
+ */
+#define container_of(p, type, member) \
+ ((type *) (((char *) (p)) - offsetof(type, member)))
+
#define _RTE_STR(x) #x
/** Take a macro value and get a string version of it */
#define RTE_STR(x) _RTE_STR(x)
--
2.9.0
[dpdk-dev] [PATCH v1 07/15] eal: get rid of pmd_type
There is no need to determine a PMD type any more. The PMD_VDEV devices
has its own list of drivers. And all PMD_PDEV are PCI devices using
a different way of registering themselfs.
Signed-off-by: Jan Viktorin
---
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 1 -
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 -
drivers/crypto/kasumi/rte_kasumi_pmd.c | 1 -
drivers/crypto/null/null_crypto_pmd.c | 1 -
drivers/crypto/snow3g/rte_snow3g_pmd.c | 1 -
drivers/net/af_packet/rte_eth_af_packet.c | 1 -
drivers/net/bonding/rte_eth_bond_pmd.c | 1 -
drivers/net/mpipe/mpipe_tilegx.c | 2 --
drivers/net/null/rte_eth_null.c| 1 -
drivers/net/pcap/rte_eth_pcap.c| 1 -
drivers/net/ring/rte_eth_ring.c| 1 -
drivers/net/vhost/rte_eth_vhost.c | 1 -
drivers/net/xenvirt/rte_eth_xenvirt.c | 1 -
lib/librte_eal/common/include/rte_dev.h| 9 -
14 files changed, 23 deletions(-)
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 6e45293..dfa1001 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -517,7 +517,6 @@ aesni_gcm_uninit(const char *name)
static struct rte_vdev_driver aesni_gcm_pmd_drv = {
.driver = {
.name = CRYPTODEV_NAME_AESNI_GCM_PMD,
- .type = PMD_VDEV,
},
.init = aesni_gcm_init,
.uninit = aesni_gcm_uninit,
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index e7cdcfd..3265f83 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -717,7 +717,6 @@ cryptodev_aesni_mb_uninit(const char *name)
static struct rte_vdev_driver cryptodev_aesni_mb_pmd_drv = {
.driver = {
.name = CRYPTODEV_NAME_AESNI_MB_PMD,
- .type = PMD_VDEV,
},
.init = cryptodev_aesni_mb_init,
.uninit = cryptodev_aesni_mb_uninit,
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c
b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index 792184a..c39b0a1 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -651,7 +651,6 @@ cryptodev_kasumi_uninit(const char *name)
static struct rte_vdev_driver cryptodev_kasumi_pmd_drv = {
.driver = {
.name = CRYPTODEV_NAME_KASUMI_PMD,
- .type = PMD_VDEV,
},
.init = cryptodev_kasumi_init,
.uninit = cryptodev_kasumi_uninit,
diff --git a/drivers/crypto/null/null_crypto_pmd.c
b/drivers/crypto/null/null_crypto_pmd.c
index 5250e3f..5ad8b86 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -271,7 +271,6 @@ cryptodev_null_uninit(const char *name)
static struct rte_vdev_driver cryptodev_null_pmd_drv = {
.driver = {
.name = CRYPTODEV_NAME_NULL_PMD,
- .type = PMD_VDEV,
},
.init = cryptodev_null_init,
.uninit = cryptodev_null_uninit,
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c
b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index 6dc9a2e..9fc5c64 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -642,7 +642,6 @@ cryptodev_snow3g_uninit(const char *name)
static struct rte_vdev_driver cryptodev_snow3g_pmd_drv = {
.driver = {
.name = CRYPTODEV_NAME_SNOW3G_PMD,
- .type = PMD_VDEV,
},
.init = cryptodev_snow3g_init,
.uninit = cryptodev_snow3g_uninit,
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index 66aaf99..9d0c6d3 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -874,7 +874,6 @@ rte_pmd_af_packet_devuninit(const char *name)
static struct rte_vdev_driver pmd_af_packet_drv = {
.driver = {
.name = "eth_af_packet",
- .type = PMD_VDEV,
},
.init = rte_pmd_af_packet_devinit,
.uninit = rte_pmd_af_packet_devuninit,
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 801a481..a3846e6 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2507,7 +2507,6 @@ bond_ethdev_configure(struct rte_eth_dev *dev)
static struct rte_vdev_driver bond_drv = {
.driver = {
.name = "eth_bond",
- .type = PMD_VDEV,
},
.init = bond_init,
.uninit = bond_uninit,
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index fe7c0c6..9d5cc6d 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -1626,7 +1626,6 @@ rte_pmd_mpipe_devinit(const char *ifname,
static struct rte_vdev_driver pmd_mpipe_xgbe_drv
[dpdk-dev] [PATCH v1 04/15] drivers: convert PMD_VDEV drivers to use rte_vdev_driver
All PMD_VDEV drivers can now use rte_vdev_driver instead of the
rte_driver (which is embedded in the rte_vdev_driver).
Signed-off-by: Jan Viktorin
---
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 16 +---
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 16 +---
drivers/crypto/kasumi/rte_kasumi_pmd.c | 16 +---
drivers/crypto/null/null_crypto_pmd.c | 16 +---
drivers/crypto/snow3g/rte_snow3g_pmd.c | 16 +---
drivers/net/af_packet/rte_eth_af_packet.c | 16 +---
drivers/net/bonding/rte_eth_bond_pmd.c | 16 +---
drivers/net/mpipe/mpipe_tilegx.c | 26 +++---
drivers/net/null/rte_eth_null.c| 16 +---
drivers/net/pcap/rte_eth_pcap.c| 16 +---
drivers/net/ring/rte_eth_ring.c| 16 +---
drivers/net/vhost/rte_eth_vhost.c | 16 +---
drivers/net/xenvirt/rte_eth_xenvirt.c | 16 +---
13 files changed, 123 insertions(+), 95 deletions(-)
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 2987ef6..e6720e8 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -37,7 +37,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -514,11 +514,13 @@ aesni_gcm_uninit(const char *name)
return 0;
}
-static struct rte_driver aesni_gcm_pmd_drv = {
- .name = CRYPTODEV_NAME_AESNI_GCM_PMD,
- .type = PMD_VDEV,
- .init = aesni_gcm_init,
- .uninit = aesni_gcm_uninit
+static struct rte_vdev_driver aesni_gcm_pmd_drv = {
+ .driver = {
+ .name = CRYPTODEV_NAME_AESNI_GCM_PMD,
+ .type = PMD_VDEV,
+ .init = aesni_gcm_init,
+ .uninit = aesni_gcm_uninit
+ },
};
-PMD_REGISTER_DRIVER(aesni_gcm_pmd_drv);
+RTE_EAL_VDRV_REGISTER(aesni_gcm_pmd_drv);
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index 6554fc4..6c6420b 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -34,7 +34,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -714,11 +714,13 @@ cryptodev_aesni_mb_uninit(const char *name)
return 0;
}
-static struct rte_driver cryptodev_aesni_mb_pmd_drv = {
- .name = CRYPTODEV_NAME_AESNI_MB_PMD,
- .type = PMD_VDEV,
- .init = cryptodev_aesni_mb_init,
- .uninit = cryptodev_aesni_mb_uninit
+static struct rte_vdev_driver cryptodev_aesni_mb_pmd_drv = {
+ .driver = {
+ .name = CRYPTODEV_NAME_AESNI_MB_PMD,
+ .type = PMD_VDEV,
+ .init = cryptodev_aesni_mb_init,
+ .uninit = cryptodev_aesni_mb_uninit
+ },
};
-PMD_REGISTER_DRIVER(cryptodev_aesni_mb_pmd_drv);
+RTE_EAL_VDRV_REGISTER(cryptodev_aesni_mb_pmd_drv);
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c
b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index 0bf415d..91181c4 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -648,11 +648,13 @@ cryptodev_kasumi_uninit(const char *name)
return 0;
}
-static struct rte_driver cryptodev_kasumi_pmd_drv = {
- .name = CRYPTODEV_NAME_KASUMI_PMD,
- .type = PMD_VDEV,
- .init = cryptodev_kasumi_init,
- .uninit = cryptodev_kasumi_uninit
+static struct rte_vdev_driver cryptodev_kasumi_pmd_drv = {
+ .driver = {
+ .name = CRYPTODEV_NAME_KASUMI_PMD,
+ .type = PMD_VDEV,
+ .init = cryptodev_kasumi_init,
+ .uninit = cryptodev_kasumi_uninit
+ },
};
-PMD_REGISTER_DRIVER(cryptodev_kasumi_pmd_drv);
+RTE_EAL_VDRV_REGISTER(cryptodev_kasumi_pmd_drv);
diff --git a/drivers/crypto/null/null_crypto_pmd.c
b/drivers/crypto/null/null_crypto_pmd.c
index bdaf13c..a015ee5 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -33,7 +33,7 @@
#include
#include
#include
-#include
+#include
#include
#include "null_crypto_pmd_private.h"
@@ -268,11 +268,13 @@ cryptodev_null_uninit(const char *name)
return 0;
}
-static struct rte_driver cryptodev_null_pmd_drv = {
- .name = CRYPTODEV_NAME_NULL_PMD,
- .type = PMD_VDEV,
- .init = cryptodev_null_init,
- .uninit = cryptodev_null_uninit
+static struct rte_vdev_driver cryptodev_null_pmd_drv = {
+ .driver = {
+ .name = CRYPTODEV_NAME_NULL_PMD,
+ .type = PMD_VDEV,
+ .init = cryptodev_null_init,
+ .uninit = cryptodev_null_uninit
+ },
};
-PMD_REGISTER_DRIVER(cryptodev_null_pmd_drv);
+RTE_EAL_VDRV_REGISTER(cryptodev_null_pmd_drv);
[dpdk-dev] [PATCH v1 03/15] eal: do not call init for PMD_PDEV drivers
There is no way how to call an init on a PMD_PDEV driver as those
drivers are all PCI drivers and they do not register any rte_driver
with EAL. We can drop the loop over PMD_PDEV drivers entirely.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_dev.c | 8
1 file changed, 8 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common/eal_common_dev.c
index f9b3d1d..f4c880c 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -67,7 +67,6 @@ int
rte_eal_dev_init(void)
{
struct rte_devargs *devargs;
- struct rte_driver *driver;
/*
* Note that the dev_driver_list is populated here
@@ -89,13 +88,6 @@ rte_eal_dev_init(void)
}
}
- /* Once the vdevs are initalized, start calling all the pdev drivers */
- TAILQ_FOREACH(driver, _driver_list, next) {
- if (driver->type != PMD_PDEV)
- continue;
- /* PDEV drivers don't get passed any parameters */
- driver->init(NULL, NULL);
- }
return 0;
}
--
2.9.0
[dpdk-dev] [PATCH v1 02/15] eal: no need to test for PMD_VDEV anymore
All devices in the rte_eal_vdev_init/uninit are always virtual devices.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_vdev.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_vdev.c
b/lib/librte_eal/common/eal_common_vdev.c
index ea83c41..5a74da8 100644
--- a/lib/librte_eal/common/eal_common_vdev.c
+++ b/lib/librte_eal/common/eal_common_vdev.c
@@ -60,9 +60,6 @@ rte_eal_vdev_init(const char *name, const char *args)
return -EINVAL;
TAILQ_FOREACH(driver, _driver_list, next) {
- if (driver->driver.type != PMD_VDEV)
- continue;
-
/*
* search a driver prefix in virtual device name.
* For example, if the driver is pcap PMD, driver->name
@@ -86,9 +83,6 @@ rte_eal_vdev_uninit(const char *name)
return -EINVAL;
TAILQ_FOREACH(driver, _driver_list, next) {
- if (driver->driver.type != PMD_VDEV)
- continue;
-
/*
* search a driver prefix in virtual device name.
* For example, if the driver is pcap PMD, driver->name
--
2.9.0
[dpdk-dev] [PATCH v1 00/15] rte_driver/device infrastructure
Hello, based on the discussions with Shreyansh, I propose a patchset with the important EAL changes. It is incomplete and I suppose to extend and change certain things in the foreseeable future. Important notes: * pmd_type is removed * introduced rte_vdev_driver inheriting rte_driver * PMD_REGISTER_DRIVER is replaced by RTE_EAL_VDRV_REGISTER * rte_driver/device integrated into rte_pci_driver/device * all drivers and devices are in 2 lists - general and bus-specific Shreyansh, I hope I do not duplicate your work. I tried to avoid touching pmd_type but it quite complicated... There is also an initial generalization of rte_pci_resource. More such generalizations are to be done. The init/uninit functions cannot be generalized easily, I think. Both PCI and VDEV have different requirements. No idea about hotplug... The patchset is based on (all rebased on top of 34d279): [PATCH v5 00/17] Prepare for rte_device / rte_driver Thanks anybody for some quick review and notes. Regards Jan -- Jan Viktorin (15): eal: extract vdev infra eal: no need to test for PMD_VDEV anymore eal: do not call init for PMD_PDEV drivers drivers: convert PMD_VDEV drivers to use rte_vdev_driver eal: move init/uninit to rte_vdev_driver eal: remove PMD_REGISTER_DRIVER eal: get rid of pmd_type eal: define macro container_of eal: rte_pci.h includes rte_dev.h eal: rename and move rte_pci_resource eal/pci: inherit rte_driver by rte_pci_driver eal: call rte_eal_driver_register eal: introduce rte_device eal/pci: inherit rte_device by rte_pci_device eal/pci: insert rte_device on scan app/test/test_pci.c| 10 ++- app/test/virtual_pmd.c | 6 +- drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 13 ++-- drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 13 ++-- drivers/crypto/kasumi/rte_kasumi_pmd.c | 13 ++-- drivers/crypto/null/null_crypto_pmd.c | 13 ++-- drivers/crypto/qat/rte_qat_cryptodev.c | 4 +- drivers/crypto/snow3g/rte_snow3g_pmd.c | 13 ++-- drivers/net/af_packet/rte_eth_af_packet.c | 11 ++-- drivers/net/bnx2x/bnx2x_ethdev.c | 8 ++- drivers/net/bonding/rte_eth_bond_pmd.c | 11 ++-- drivers/net/cxgbe/cxgbe_ethdev.c | 4 +- drivers/net/cxgbe/sge.c| 6 +- drivers/net/e1000/em_ethdev.c | 4 +- drivers/net/e1000/igb_ethdev.c | 8 ++- drivers/net/ena/ena_ethdev.c | 4 +- drivers/net/enic/enic_ethdev.c | 4 +- drivers/net/fm10k/fm10k_ethdev.c | 10 +-- drivers/net/i40e/i40e_ethdev.c | 4 +- drivers/net/i40e/i40e_ethdev_vf.c | 4 +- drivers/net/i40e/i40e_fdir.c | 2 +- drivers/net/ixgbe/ixgbe_ethdev.c | 8 ++- drivers/net/mlx4/mlx4.c| 4 +- drivers/net/mlx5/mlx5.c| 4 +- drivers/net/mpipe/mpipe_tilegx.c | 20 +++--- drivers/net/nfp/nfp_net.c | 4 +- drivers/net/null/rte_eth_null.c| 11 ++-- drivers/net/pcap/rte_eth_pcap.c| 11 ++-- drivers/net/qede/qede_ethdev.c | 4 ++ drivers/net/ring/rte_eth_ring.c| 11 ++-- drivers/net/szedata2/rte_eth_szedata2.c| 8 ++- drivers/net/vhost/rte_eth_vhost.c | 11 ++-- drivers/net/virtio/virtio_ethdev.c | 6 +- drivers/net/virtio/virtio_pci.c| 2 +- drivers/net/vmxnet3/vmxnet3_ethdev.c | 7 +- drivers/net/vmxnet3/vmxnet3_rxtx.c | 2 +- drivers/net/xenvirt/rte_eth_xenvirt.c | 11 ++-- lib/librte_cryptodev/rte_cryptodev.c | 6 +- lib/librte_eal/bsdapp/eal/Makefile | 1 + lib/librte_eal/common/Makefile | 2 +- lib/librte_eal/common/eal_common_dev.c | 67 +++ lib/librte_eal/common/eal_common_pci.c | 20 +++--- lib/librte_eal/common/eal_common_vdev.c| 100 + lib/librte_eal/common/include/rte_common.h | 16 + lib/librte_eal/common/include/rte_dev.h| 54 +--- lib/librte_eal/common/include/rte_pci.h| 20 ++ lib/librte_eal/common/include/rte_vdev.h | 96 +++ lib/librte_eal/linuxapp/eal/Makefile | 1 + lib/librte_eal/linuxapp/eal/eal_ivshmem.c | 2 +- lib/librte_eal/linuxapp/eal/eal_pci.c | 7 +- lib/librte_ether/rte_ethdev.c | 16 +++-- 51 files changed, 468 insertions(+), 229 deletions(-) create mode 100644 lib/librte_eal/common/eal_common_vdev.c create mode 100644 lib/librte_eal/common/include/rte_vdev.h -- 2.9.0
[dpdk-dev] [PATCH v2 00/11] Fix build errors related to exported headers
Hi Adrien, I am the only one in CC and only in the 00/11 patch. Is it a mistake? Or what is the purpose? Regards? Jan?Viktorin RehiveTech Sent?from?a?mobile?device ? P?vodn? zpr?va ? Od: Adrien Mazarguil Odesl?no: ?ter?, 5. ?ervence 2016 12:45 Komu: dev at dpdk.org Kopie: Jan Viktorin P?edm?t: [PATCH v2 00/11] Fix build errors related to exported headers DPDK uses GNU C language extensions in most of its code base. This is fine for internal source files whose compilation flags are controlled by DPDK, however user applications that use exported "public" headers may experience compilation failures when enabling strict error/standard checks (-std and -pedantic for instance). Exported headers are installed system-wide and must be as clean as possible so applications do not have to resort to workarounds. This patchset affects exported headers only, compilation problems are addressed as follows: - Adding the __extension__ keyword to nonstandard constructs (same method as existing libraries when there is no other choice). - Adding the __extension__ keyword to C11 constructs to remain compatible with pure C99. - Adding missing includes so exported files can be included out of order and on their own. - Fixing GNU printf-like variadic macros as there is no magic keyword for these. Changes in v2: - Rebased on top of the current HEAD. - Added script to check headers automatically (check-includes.sh), for both C and C++ compilation. - Updated test-build.sh to use it. - Fixed consistency of new #include directives, now inside extern "C" blocks for files that already do that (Jan, fixing these was too much work for this patchset so I settled on this solution in the meantime). - Updated headlines to address check-git-log.sh complaints. Adrien Mazarguil (11): lib: work around braced-groups within expressions lib: work around large enum values lib: use C99 syntax for zero-size arrays lib: work around nonstandard bit-fields lib: work around structs with no members lib: work around unnamed structs/unions lib: add missing include dependencies lib: work around forward reference to enum types lib: remove named variadic macros in exported headers lib: hide static functions never defined scripts: check compilation of exported header files MAINTAINERS | 1 + lib/librte_acl/rte_acl.h | 2 +- lib/librte_cfgfile/rte_cfgfile.h | 2 + lib/librte_cmdline/cmdline.h | 1 + lib/librte_cmdline/cmdline_parse_portlist.h | 1 + lib/librte_cmdline/cmdline_socket.h | 3 + lib/librte_cryptodev/rte_crypto.h | 2 + lib/librte_cryptodev/rte_crypto_sym.h | 3 + lib/librte_cryptodev/rte_cryptodev.h | 40 ++- lib/librte_cryptodev/rte_cryptodev_pmd.h | 6 +- .../common/include/arch/arm/rte_byteorder.h | 2 + .../common/include/arch/arm/rte_memcpy_32.h | 3 +- .../common/include/arch/arm/rte_prefetch_32.h | 1 + .../common/include/arch/arm/rte_prefetch_64.h | 1 + .../common/include/arch/arm/rte_vect.h | 1 + .../common/include/arch/ppc_64/rte_atomic.h | 1 + .../common/include/arch/ppc_64/rte_byteorder.h | 1 + .../common/include/arch/ppc_64/rte_cycles.h | 2 + .../common/include/arch/ppc_64/rte_memcpy.h | 3 +- .../common/include/arch/ppc_64/rte_prefetch.h | 1 + .../common/include/arch/x86/rte_atomic.h | 2 + .../common/include/arch/x86/rte_atomic_32.h | 9 + .../common/include/arch/x86/rte_atomic_64.h | 8 + .../common/include/arch/x86/rte_byteorder.h | 2 + .../common/include/arch/x86/rte_byteorder_32.h | 7 + .../common/include/arch/x86/rte_byteorder_64.h | 7 + .../common/include/arch/x86/rte_cycles.h | 2 + .../common/include/arch/x86/rte_memcpy.h | 4 +- .../common/include/arch/x86/rte_prefetch.h | 1 + .../common/include/arch/x86/rte_rtm.h | 1 + .../common/include/arch/x86/rte_vect.h | 8 +- .../common/include/generic/rte_atomic.h | 1 + .../common/include/generic/rte_byteorder.h | 2 + .../common/include/generic/rte_cpuflags.h | 3 + .../common/include/generic/rte_memcpy.h | 4 + lib/librte_eal/common/include/rte_common.h | 22 +- lib/librte_eal/common/include/rte_devargs.h | 1 + lib/librte_eal/common/include/rte_eal.h | 1 + lib/librte_eal/common/include/rte_interrupts.h | 2 + lib/librte_eal/common/include/rte_memory.h | 4 + lib/librte_eal/common/include/rte_memzone.h | 2 + lib/librte_eal/common/include/rte_time.h | 8 + lib/librte_eal/common/include/rte_version.h | 1 + .../eal/include/exec-env/rte_interrupts.h | 1 + .../eal/include/exec-env/rte_kni_common.h | 6 +- lib/librte_ether/rte_dev_info.h | 2 + lib/librte_ether/rte_eth_ctrl.h | 4 + lib/librte_ether/rte_ethdev.h | 4 + lib/librte_hash/rte_fbk_hash.h | 2 +- lib/librte_hash/rte_thash.h | 3 + lib/librte_ip_frag/rte_ip_frag.h | 2 +- lib/librte_lpm/rte_lpm.h | 7 +- lib/librte_lpm/rte_lpm_neon.h | 1 + lib/librte_lpm/rte_lpm_sse.h | 1 + lib/librte_mbuf/rte_mbuf.h | 9 + lib/librte_mempool/rte_mempool.h | 3 + lib/librte_pdump/rte_pdump.h | 4 + lib/librte_pipeline/rte_pipeline.h | 4 +- lib/librte_reorder/rte_reorder.h | 2 + lib/librte_ring/rte_ring.h | 2 +- lib/librte_sched/rte_bitmap.h | 3
[dpdk-dev] [PATCH v1 28/28] ether: support SoC device/driver
Hello Shreyansh, ? > On Monday 04 July 2016 08:06 PM, Jan Viktorin wrote: >> On Mon, 4 Jul 2016 19:57:18 +0530 >> Shreyansh jain wrote: >> >> [...] >> >>>>>> @@ -1431,7 +1524,7 @@ >rte_eth_dev_info_get(uint8_t port_id, struct >>>>>> >rte_eth_dev_info *dev_info) >>>>>> >>>>>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->>dev_infos_get); >>>>>> (*dev->dev_ops->dev_infos_get)(dev, dev_info); >>>>>> -dev_info->pci_dev = dev->pci_dev; >>>>>> +dev_info->soc_dev = dev->soc_dev; >>>>> >>>>> I think both the members, pci_dev and soc_dev, should be updated by this >>>>> call. >>>>> Is there some specific reason why soc_dev is the only one which is >>>>> getting updated? >>>> >>>> Yes, looks like a mistake. Thanks! And sorry for delayed reply. >>> >>> No problems - thanks for confirmation. >>> I have gone through almost complete series and as and when you rebase it, >>> it would have my ACK. >> >> OK, thanks. That's what I am playing with right now. I've rebased on v3 of >> this patch. There will >> be some more tests in my v2. >> >>> rte_driver patchset which I sent last are broken - I will publish an >>> updated version very soon. >> >> I am surprised that you've changed the args to RTE_EAL_PCI_REGISTER... Are >> you sure about this step? >> I wrote that I'll change it myself for v2 for SoC to accept name and pointer >> as it was originally for PCI... > > Really? Then probably I understood it wrong. I don't have any issues with the > first one as well but just for slightly cleaner approach I thought of going > with your suggest (or, suggestion as understood by me). ?> > Anyways the patch is broken and doesn't apply on master. I will push a new > version (with revert EAL_PCI_REGISTER arguments) within today. Ok. I am away for few days this week but I will continue as soon as possible on the soc patchset and also on the rte_device/driver issue. We have to cut this as soon as possible. I think the best would be to post a small patchset on top of this one introducing the change. I think, there should be a single list of rte_device and a list for rte_driver while preserving lists for each infra, so also rte_pci_device would have a separate list. Then, it's possible to iterate over all PCI devices easily and iterate over all devices generically at the same time. What I am not sure about are addr and id things. It's quite difficult to generalize them. The addr needs a conpare function but how to compare pci addr to another type of addr? Do we need this? If so, I'll work on this. Another thing - resources. Do we want to have a kind of a generic rte_resource instead of rte_pci_resource? I think this is clearly possible. I am about to do this. I am afraid we are unable to change devargs significantly in this release :/ (due to time and lack of a discussion here).??What I really like to see is the virtual device conversion and pmd_type removal. Are you able to look at this? Any other objections? Jan Viktorin RehiveTech Sent from a mobile device? >> >> Jan >>? > >- >Shreyansh
[dpdk-dev] [PATCH v3 16/16] vfio: change VFIO init to be extendable
We can now just OR the vfio_enabled sequentially and so adding new VFIO
subsystems (vfio_platform) is possible.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 606b777..3fb2188 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -705,12 +705,14 @@ rte_eal_iopl_init(void)
#ifdef VFIO_PRESENT
static int rte_eal_vfio_setup(void)
{
- if (internal_config.no_pci)
- return 0;
+ int vfio_enabled = 0;
- pci_vfio_enable();
+ if (!internal_config.no_pci) {
+ pci_vfio_enable();
+ vfio_enabled |= pci_vfio_is_enabled();
+ }
- if (pci_vfio_is_enabled()) {
+ if (vfio_enabled) {
/* if we are primary process, create a thread to communicate
with
* secondary processes. the thread will use a socket to wait for
--
2.8.0
[dpdk-dev] [PATCH v3 15/16] vfio: initialize vfio out of the PCI subsystem
The VFIO does not depend on the PCI anymore so it can be initialized out of
the PCI subsystem.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal.c | 31 ++
lib/librte_eal/linuxapp/eal/eal_pci.c | 17 +---
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 3 ---
lib/librte_eal/linuxapp/eal/eal_vfio.h | 3 +++
4 files changed, 35 insertions(+), 19 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 543ef86..606b777 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -82,6 +82,7 @@
#include "eal_filesystem.h"
#include "eal_hugepages.h"
#include "eal_options.h"
+#include "eal_vfio.h"
#define MEMSIZE_IF_NO_HUGE_PAGE (64ULL * 1024ULL * 1024ULL)
@@ -701,6 +702,31 @@ rte_eal_iopl_init(void)
return 0;
}
+#ifdef VFIO_PRESENT
+static int rte_eal_vfio_setup(void)
+{
+ if (internal_config.no_pci)
+ return 0;
+
+ pci_vfio_enable();
+
+ if (pci_vfio_is_enabled()) {
+
+ /* if we are primary process, create a thread to communicate
with
+* secondary processes. the thread will use a socket to wait for
+* requests from secondary process to send open file
descriptors,
+* because VFIO does not allow multiple open descriptors on a
group or
+* VFIO container.
+*/
+ if (internal_config.process_type == RTE_PROC_PRIMARY &&
+ vfio_mp_sync_setup() < 0)
+ return -1;
+ }
+
+ return 0;
+}
+#endif
+
/* Launch threads, called at application init(). */
int
rte_eal_init(int argc, char **argv)
@@ -764,6 +790,11 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_pci_init() < 0)
rte_panic("Cannot init PCI\n");
+#ifdef VFIO_PRESENT
+ if (rte_eal_vfio_setup() < 0)
+ rte_panic("Cannot init VFIO\n");
+#endif
+
#ifdef RTE_LIBRTE_IVSHMEM
if (rte_eal_ivshmem_init() < 0)
rte_panic("Cannot init IVSHMEM\n");
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index d0a6481..cd9de7c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -754,21 +754,6 @@ rte_eal_pci_init(void)
RTE_LOG(ERR, EAL, "%s(): Cannot scan PCI bus\n", __func__);
return -1;
}
-#ifdef VFIO_PRESENT
- pci_vfio_enable();
-
- if (pci_vfio_is_enabled()) {
-
- /* if we are primary process, create a thread to communicate
with
-* secondary processes. the thread will use a socket to wait for
-* requests from secondary process to send open file
descriptors,
-* because VFIO does not allow multiple open descriptors on a
group or
-* VFIO container.
-*/
- if (internal_config.process_type == RTE_PROC_PRIMARY &&
- vfio_mp_sync_setup() < 0)
- return -1;
- }
-#endif
+
return 0;
}
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
index 62c337f..6a960d1 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
@@ -74,9 +74,6 @@ int pci_uio_ioport_unmap(struct rte_pci_ioport *p);
#ifdef VFIO_PRESENT
-int pci_vfio_enable(void);
-int pci_vfio_is_enabled(void);
-
/* access config space */
int pci_vfio_read_config(const struct rte_intr_handle *intr_handle,
void *buf, size_t len, off_t offs);
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index 884884c..43960eb 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.h
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h
@@ -143,6 +143,9 @@ int vfio_setup_device(const char *sysfs_base, const char
*dev_addr,
int vfio_enable(const char *modname);
int vfio_is_enabled(const char *modname);
+int pci_vfio_enable(void);
+int pci_vfio_is_enabled(void);
+
#define SOCKET_REQ_CONTAINER 0x100
#define SOCKET_REQ_GROUP 0x200
#define SOCKET_OK 0x0
--
2.8.0
[dpdk-dev] [PATCH v3 14/16] vfio: rename and generalize eal_pci_vfio_mp_sync
The module eal_pci_vfio_mp_sync is quite generic so it shouldn't contain the
"pci" string in its name. The internal functions don't need the pci_* prefix.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/Makefile | 4 ++--
lib/librte_eal/linuxapp/eal/eal_pci.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_pci_init.h| 1 -
lib/librte_eal/linuxapp/eal/eal_vfio.h| 2 ++
.../linuxapp/eal/{eal_pci_vfio_mp_sync.c => eal_vfio_mp_sync.c} | 8
5 files changed, 9 insertions(+), 8 deletions(-)
rename lib/librte_eal/linuxapp/eal/{eal_pci_vfio_mp_sync.c =>
eal_vfio_mp_sync.c} (98%)
diff --git a/lib/librte_eal/linuxapp/eal/Makefile
b/lib/librte_eal/linuxapp/eal/Makefile
index 517554f..1a97693 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -67,10 +67,10 @@ endif
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_thread.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_log.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_vfio.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_vfio_mp_sync.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci_uio.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci_vfio.c
-SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci_vfio_mp_sync.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_debug.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_lcore.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_timer.c
@@ -111,7 +111,7 @@ CFLAGS_eal_common_cpuflags.o := $(CPUFLAGS_LIST)
CFLAGS_eal.o := -D_GNU_SOURCE
CFLAGS_eal_interrupts.o := -D_GNU_SOURCE
-CFLAGS_eal_pci_vfio_mp_sync.o := -D_GNU_SOURCE
+CFLAGS_eal_vfio_mp_sync.o := -D_GNU_SOURCE
CFLAGS_eal_timer.o := -D_GNU_SOURCE
CFLAGS_eal_lcore.o := -D_GNU_SOURCE
CFLAGS_eal_thread.o := -D_GNU_SOURCE
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index f9c3efd..d0a6481 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -766,7 +766,7 @@ rte_eal_pci_init(void)
* VFIO container.
*/
if (internal_config.process_type == RTE_PROC_PRIMARY &&
- pci_vfio_mp_sync_setup() < 0)
+ vfio_mp_sync_setup() < 0)
return -1;
}
#endif
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
index d00bf7d..62c337f 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
@@ -76,7 +76,6 @@ int pci_uio_ioport_unmap(struct rte_pci_ioport *p);
int pci_vfio_enable(void);
int pci_vfio_is_enabled(void);
-int pci_vfio_mp_sync_setup(void);
/* access config space */
int pci_vfio_read_config(const struct rte_intr_handle *intr_handle,
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index f1a5427..884884c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.h
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h
@@ -149,6 +149,8 @@ int vfio_is_enabled(const char *modname);
#define SOCKET_NO_FD 0x1
#define SOCKET_ERR 0xFF
+int vfio_mp_sync_setup(void);
+
#define VFIO_PRESENT
#endif /* kernel version */
#endif /* RTE_EAL_VFIO */
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
b/lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
similarity index 98%
rename from lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
rename to lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
index b3f4c51..00cf919 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio_mp_sync.c
@@ -265,7 +265,7 @@ vfio_mp_sync_connect_to_primary(void)
* socket listening thread for primary process
*/
static __attribute__((noreturn)) void *
-pci_vfio_mp_sync_thread(void __rte_unused * arg)
+vfio_mp_sync_thread(void __rte_unused * arg)
{
int ret, fd, vfio_group_no;
@@ -376,7 +376,7 @@ vfio_mp_sync_socket_setup(void)
* set up a local socket and tell it to listen for incoming connections
*/
int
-pci_vfio_mp_sync_setup(void)
+vfio_mp_sync_setup(void)
{
int ret;
char thread_name[RTE_MAX_THREAD_NAME_LEN];
@@ -387,7 +387,7 @@ pci_vfio_mp_sync_setup(void)
}
ret = pthread_create(_thread, NULL,
- pci_vfio_mp_sync_thread, NULL);
+ vfio_mp_sync_thread, NULL);
if (ret) {
RTE_LOG(ERR, EAL,
"Failed to create thread for communication with
secondary processes!\n");
@@ -396,7 +396,7 @@ pci_vfio_mp_sync_setup(void)
}
/* Set thread_name for aid in debugging. */
- snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN, "pci-vfio-sync");
+ snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN, "vfio-sync");
[dpdk-dev] [PATCH v3 13/16] vfio: make vfio_*_dma_map and iommu_types private
There is no more reason to expose those definitions as nobody uses them.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_vfio.c | 15 +--
lib/librte_eal/linuxapp/eal/eal_vfio.h | 11 ---
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index d11f723..fcb0ab3 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -49,6 +49,17 @@
/* per-process VFIO config */
static struct vfio_config vfio_cfg;
+static int vfio_type1_dma_map(int);
+static int vfio_noiommu_dma_map(int);
+
+/* IOMMU types we support */
+static const struct vfio_iommu_type iommu_types[] = {
+ /* x86 IOMMU, otherwise known as type 1 */
+ { RTE_VFIO_TYPE1, "Type 1", _type1_dma_map},
+ /* IOMMU-less mode */
+ { RTE_VFIO_NOIOMMU, "No-IOMMU", _noiommu_dma_map},
+};
+
int
vfio_get_group_fd(int iommu_group_no)
{
@@ -494,7 +505,7 @@ vfio_get_group_no(const char *sysfs_base,
return 1;
}
-int
+static int
vfio_type1_dma_map(int vfio_container_fd)
{
const struct rte_memseg *ms = rte_eal_get_physmem_layout();
@@ -526,7 +537,7 @@ vfio_type1_dma_map(int vfio_container_fd)
return 0;
}
-int
+static int
vfio_noiommu_dma_map(int __rte_unused vfio_container_fd)
{
/* No-IOMMU mode does not need DMA mapping */
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index 4ca0fa3..f1a5427 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.h
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h
@@ -149,17 +149,6 @@ int vfio_is_enabled(const char *modname);
#define SOCKET_NO_FD 0x1
#define SOCKET_ERR 0xFF
-int vfio_type1_dma_map(int);
-int vfio_noiommu_dma_map(int);
-
-/* IOMMU types we support */
-static const struct vfio_iommu_type iommu_types[] = {
- /* x86 IOMMU, otherwise known as type 1 */
- { RTE_VFIO_TYPE1, "Type 1", _type1_dma_map},
- /* IOMMU-less mode */
- { RTE_VFIO_NOIOMMU, "No-IOMMU", _noiommu_dma_map},
-};
-
#define VFIO_PRESENT
#endif /* kernel version */
#endif /* RTE_EAL_VFIO */
--
2.8.0
[dpdk-dev] [PATCH v3 12/16] vfio: fix typo in doc for vfio_setup_device
Signed-off-by: Jan Viktorin Suggested-by: Anatoly Burakov Acked-by: John McNamara --- lib/librte_eal/linuxapp/eal/eal_vfio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h b/lib/librte_eal/linuxapp/eal/eal_vfio.h index d4532a5..4ca0fa3 100644 --- a/lib/librte_eal/linuxapp/eal/eal_vfio.h +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h @@ -131,7 +131,7 @@ int vfio_get_group_fd(int iommu_group_no); /** - * Setup vfio_cfg for the device indentified by its address. It discovers + * Setup vfio_cfg for the device identified by its address. It discovers * the configured I/O MMU groups or sets a new one for the device. If a new * groups is assigned, the DMA mapping is performed. * Returns 0 on success, a negative value on failure and a positive value in -- 2.8.0
[dpdk-dev] [PATCH v3 11/16] vfio: move global vfio_cfg to eal_vfio.c
The vfio_cfg is a module-global variable and so together with this
variable, it is necessary to move functions:
* pci_vfio_get_group_fd
- renamed to vfio_get_group_fd
- pci_* version removed (no other call in EAL)
* pci_vfio_setup_device
- renamed as vfio_setup_device
* pci_vfio_enable
- renamed as vfio_enable
- generalized to check for a specific vfio driver presence
- pci_* specialization preserved as a wrapper
* pci_vfio_is_enabled
- renamed as vfio_is_enabled
- generalized to check for a specific vfio driver presence
to preserve the semantics of VFIO + PCI
- pci_* specialization preserved as a wrapper
* clear_current_group
- private function, just moved
To stop GCC complaining about "defined but not used", the private
function pci_vfio_get_group_no has been removed entirely.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 1 -
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 297 +
lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_vfio.c | 287
lib/librte_eal/linuxapp/eal/eal_vfio.h | 17 ++
5 files changed, 309 insertions(+), 295 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
index d34212b..d00bf7d 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
@@ -94,7 +94,6 @@ int pci_vfio_ioport_unmap(struct rte_pci_ioport *p);
/* map VFIO resource prototype */
int pci_vfio_map_resource(struct rte_pci_device *dev);
-int pci_vfio_get_group_fd(int iommu_group_fd);
#endif
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 2792c23..46cd683 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -69,9 +69,6 @@ static struct rte_tailq_elem rte_vfio_tailq = {
};
EAL_REGISTER_TAILQ(rte_vfio_tailq)
-/* per-process VFIO config */
-static struct vfio_config vfio_cfg;
-
int
pci_vfio_read_config(const struct rte_intr_handle *intr_handle,
void *buf, size_t len, off_t offs)
@@ -299,255 +296,6 @@ pci_vfio_setup_interrupts(struct rte_pci_device *dev, int
vfio_dev_fd)
return -1;
}
-/* open group fd or get an existing one */
-int
-pci_vfio_get_group_fd(int iommu_group_no)
-{
- int i;
- int vfio_group_fd;
- char filename[PATH_MAX];
-
- /* check if we already have the group descriptor open */
- for (i = 0; i < vfio_cfg.vfio_group_idx; i++)
- if (vfio_cfg.vfio_groups[i].group_no == iommu_group_no)
- return vfio_cfg.vfio_groups[i].fd;
-
- /* if primary, try to open the group */
- if (internal_config.process_type == RTE_PROC_PRIMARY) {
- /* try regular group format */
- snprintf(filename, sizeof(filename),
-VFIO_GROUP_FMT, iommu_group_no);
- vfio_group_fd = open(filename, O_RDWR);
- if (vfio_group_fd < 0) {
- /* if file not found, it's not an error */
- if (errno != ENOENT) {
- RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
filename,
- strerror(errno));
- return -1;
- }
-
- /* special case: try no-IOMMU path as well */
- snprintf(filename, sizeof(filename),
- VFIO_NOIOMMU_GROUP_FMT, iommu_group_no);
- vfio_group_fd = open(filename, O_RDWR);
- if (vfio_group_fd < 0) {
- if (errno != ENOENT) {
- RTE_LOG(ERR, EAL, "Cannot open %s:
%s\n", filename,
- strerror(errno));
- return -1;
- }
- return 0;
- }
- /* noiommu group found */
- }
-
- /* if the fd is valid, create a new group for it */
- if (vfio_cfg.vfio_group_idx == VFIO_MAX_GROUPS) {
- RTE_LOG(ERR, EAL, "Maximum number of VFIO groups
reached!\n");
- close(vfio_group_fd);
- return -1;
- }
- vfio_cfg.vfio_groups[vfio_cfg.vfio_group_idx].group_no =
iommu_group_no;
- vfio_cfg.vfio_groups[vfio_cfg.vfio_group_idx].fd =
vfio_group_fd;
- return vfio_group_fd;
- }
- /* if we're in a secondary process, request group fd from the primary
-* process via our socket
-*/
[dpdk-dev] [PATCH v3 10/16] vfio: extract setup logic out of pci_vfio_map_resource
The setup logic access the global vfio_cfg variable that will be moved in the
following commits. We need to separate all accesses to this variable to a
general code.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 85 +-
1 file changed, 49 insertions(+), 36 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index c2ff465..2792c23 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -411,37 +411,22 @@ clear_current_group(void)
vfio_cfg.vfio_groups[vfio_cfg.vfio_group_idx].fd = -1;
}
-
-/*
- * map the PCI resources of a PCI device in virtual memory (VFIO version).
- * primary and secondary processes follow almost exactly the same path
+/**
+ * Setup vfio_cfg for the device indentified by its address. It discovers
+ * the configured I/O MMU groups or sets a new one for the device. If a new
+ * groups is assigned, the DMA mapping is performed.
+ * Returns 0 on success, a negative value on failure and a positive value in
+ * case the given device cannot be managed this way.
*/
-int
-pci_vfio_map_resource(struct rte_pci_device *dev)
+static int pci_vfio_setup_device(const char *pci_addr, int *vfio_dev_fd,
+ struct vfio_device_info *device_info)
{
struct vfio_group_status group_status = {
.argsz = sizeof(group_status)
};
- struct vfio_device_info device_info = { .argsz = sizeof(device_info) };
- int vfio_group_fd, vfio_dev_fd;
+ int vfio_group_fd;
int iommu_group_no;
- char pci_addr[PATH_MAX] = {0};
- struct rte_pci_addr *loc = >addr;
- int i, ret, msix_bar;
- struct mapped_pci_resource *vfio_res = NULL;
- struct mapped_pci_res_list *vfio_res_list =
RTE_TAILQ_CAST(rte_vfio_tailq.head, mapped_pci_res_list);
-
- struct pci_map *maps;
- uint32_t msix_table_offset = 0;
- uint32_t msix_table_size = 0;
- uint32_t ioport_bar;
-
- dev->intr_handle.fd = -1;
- dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN;
-
- /* store PCI address string */
- snprintf(pci_addr, sizeof(pci_addr), PCI_PRI_FMT,
- loc->domain, loc->bus, loc->devid, loc->function);
+ int ret;
/* get group number */
ret = pci_vfio_get_group_no(pci_addr, _group_no);
@@ -476,8 +461,8 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
}
/*
-* at this point, we know at least one port on this device is bound to
VFIO,
-* so we can proceed to try and set this particular port up
+* at this point, we know that this group is viable (meaning, all
devices
+* are either bound to VFIO or not bound to anything)
*/
/* check if the group is viable */
@@ -495,11 +480,6 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
return -1;
}
- /*
-* at this point, we know that this group is viable (meaning, all
devices
-* are either bound to VFIO or not bound to anything)
-*/
-
/* check if group does not have a container yet */
if (!(group_status.flags & VFIO_GROUP_FLAGS_CONTAINER_SET)) {
@@ -546,8 +526,8 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
}
/* get a file descriptor for the device */
- vfio_dev_fd = ioctl(vfio_group_fd, VFIO_GROUP_GET_DEVICE_FD, pci_addr);
- if (vfio_dev_fd < 0) {
+ *vfio_dev_fd = ioctl(vfio_group_fd, VFIO_GROUP_GET_DEVICE_FD, pci_addr);
+ if (*vfio_dev_fd < 0) {
/* if we cannot get a device fd, this simply means that this
* particular port is not bound to VFIO
*/
@@ -557,14 +537,47 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
}
/* test and setup the device */
- ret = ioctl(vfio_dev_fd, VFIO_DEVICE_GET_INFO, _info);
+ ret = ioctl(*vfio_dev_fd, VFIO_DEVICE_GET_INFO, device_info);
if (ret) {
RTE_LOG(ERR, EAL, " %s cannot get device info, "
"error %i (%s)\n", pci_addr, errno,
strerror(errno));
- close(vfio_dev_fd);
+ close(*vfio_dev_fd);
return -1;
}
+ return 0;
+}
+
+/*
+ * map the PCI resources of a PCI device in virtual memory (VFIO version).
+ * primary and secondary processes follow almost exactly the same path
+ */
+int
+pci_vfio_map_resource(struct rte_pci_device *dev)
+{
+ struct vfio_device_info device_info = { .argsz = sizeof(device_info) };
+ char pci_addr[PATH_MAX] = {0};
+ int vfio_dev_fd;
+ struct rte_pci_addr *loc = >addr;
+ int i, ret, msix_bar;
+ struct mapped_pci_resource *vfio_res = NULL;
+ struct mapped_pci_res_list *vfio_res_list =
RTE_TAILQ_CAST(rte_vfio_tailq.head
[dpdk-dev] [PATCH v3 09/16] vfio: generalize pci_vfio_get_group_no
Generalize the pci_vfio_get_group_no to not be PCI-specific. Move the general
implementation to the eal_vfio.c as vfio_get_group_no and leave the original
pci_vfio_get_group_no being a wrapper around this to preserve compilation
issues. The pci_vfio_get_group_no function will be removed later.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 38 +-
lib/librte_eal/linuxapp/eal/eal_vfio.c | 43 ++
lib/librte_eal/linuxapp/eal/eal_vfio.h | 7 +
3 files changed, 51 insertions(+), 37 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 528479a..c2ff465 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -401,43 +401,7 @@ pci_vfio_get_group_fd(int iommu_group_no)
static int
pci_vfio_get_group_no(const char *pci_addr, int *iommu_group_no)
{
- char linkname[PATH_MAX];
- char filename[PATH_MAX];
- char *tok[16], *group_tok, *end;
- int ret;
-
- memset(linkname, 0, sizeof(linkname));
- memset(filename, 0, sizeof(filename));
-
- /* try to find out IOMMU group for this device */
- snprintf(linkname, sizeof(linkname),
-"%s/%s/iommu_group", pci_get_sysfs_path(), pci_addr);
-
- ret = readlink(linkname, filename, sizeof(filename));
-
- /* if the link doesn't exist, no VFIO for us */
- if (ret < 0)
- return 0;
-
- ret = rte_strsplit(filename, sizeof(filename),
- tok, RTE_DIM(tok), '/');
-
- if (ret <= 0) {
- RTE_LOG(ERR, EAL, " %s cannot get IOMMU group\n", pci_addr);
- return -1;
- }
-
- /* IOMMU group is always the last token */
- errno = 0;
- group_tok = tok[ret - 1];
- end = group_tok;
- *iommu_group_no = strtol(group_tok, , 10);
- if ((end != group_tok && *end != '\0') || errno != 0) {
- RTE_LOG(ERR, EAL, " %s error parsing IOMMU number!\n",
pci_addr);
- return -1;
- }
-
- return 1;
+ return vfio_get_group_no(pci_get_sysfs_path(), pci_addr,
iommu_group_no);
}
static void
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index 5660ddd..2bf810e 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -165,6 +165,49 @@ vfio_get_container_fd(void)
}
int
+vfio_get_group_no(const char *sysfs_base,
+ const char *dev_addr, int *iommu_group_no)
+{
+ char linkname[PATH_MAX];
+ char filename[PATH_MAX];
+ char *tok[16], *group_tok, *end;
+ int ret;
+
+ memset(linkname, 0, sizeof(linkname));
+ memset(filename, 0, sizeof(filename));
+
+ /* try to find out IOMMU group for this device */
+ snprintf(linkname, sizeof(linkname),
+"%s/%s/iommu_group", sysfs_base, dev_addr);
+
+ ret = readlink(linkname, filename, sizeof(filename));
+
+ /* if the link doesn't exist, no VFIO for us */
+ if (ret < 0)
+ return 0;
+
+ ret = rte_strsplit(filename, sizeof(filename),
+ tok, RTE_DIM(tok), '/');
+
+ if (ret <= 0) {
+ RTE_LOG(ERR, EAL, " %s cannot get IOMMU group\n", dev_addr);
+ return -1;
+ }
+
+ /* IOMMU group is always the last token */
+ errno = 0;
+ group_tok = tok[ret - 1];
+ end = group_tok;
+ *iommu_group_no = strtol(group_tok, , 10);
+ if ((end != group_tok && *end != '\0') || errno != 0) {
+ RTE_LOG(ERR, EAL, " %s error parsing IOMMU number!\n",
dev_addr);
+ return -1;
+ }
+
+ return 1;
+}
+
+int
vfio_type1_dma_map(int vfio_container_fd)
{
const struct rte_memseg *ms = rte_eal_get_physmem_layout();
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index 0fb05a4..619cd6b 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.h
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h
@@ -119,6 +119,13 @@ vfio_has_supported_extensions(int vfio_container_fd);
int
vfio_get_container_fd(void);
+/* parse IOMMU group number for a device
+ * returns 1 on success, -1 for errors, 0 for non-existent group
+ */
+int
+vfio_get_group_no(const char *sysfs_base,
+ const char *dev_addr, int *iommu_group_no);
+
#define SOCKET_REQ_CONTAINER 0x100
#define SOCKET_REQ_GROUP 0x200
#define SOCKET_OK 0x0
--
2.8.0
[dpdk-dev] [PATCH v3 08/16] vfio: generalize pci_vfio_get_container_fd
The pci_vfio_get_container_fd is not PCI-specific. Move the implementation to
the eal_vfio.c as vfio_get_container_fd. No other code seems to call this
function.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 1 -
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 67 +---
lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_vfio.c | 72 ++
lib/librte_eal/linuxapp/eal/eal_vfio.h | 4 ++
5 files changed, 78 insertions(+), 68 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
index 883787f..d34212b 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
@@ -95,7 +95,6 @@ int pci_vfio_ioport_unmap(struct rte_pci_ioport *p);
/* map VFIO resource prototype */
int pci_vfio_map_resource(struct rte_pci_device *dev);
int pci_vfio_get_group_fd(int iommu_group_fd);
-int pci_vfio_get_container_fd(void);
#endif
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index f93db4a..528479a 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -299,71 +299,6 @@ pci_vfio_setup_interrupts(struct rte_pci_device *dev, int
vfio_dev_fd)
return -1;
}
-/* open container fd or get an existing one */
-int
-pci_vfio_get_container_fd(void)
-{
- int ret, vfio_container_fd;
-
- /* if we're in a primary process, try to open the container */
- if (internal_config.process_type == RTE_PROC_PRIMARY) {
- vfio_container_fd = open(VFIO_CONTAINER_PATH, O_RDWR);
- if (vfio_container_fd < 0) {
- RTE_LOG(ERR, EAL, " cannot open VFIO container, "
- "error %i (%s)\n", errno,
strerror(errno));
- return -1;
- }
-
- /* check VFIO API version */
- ret = ioctl(vfio_container_fd, VFIO_GET_API_VERSION);
- if (ret != VFIO_API_VERSION) {
- if (ret < 0)
- RTE_LOG(ERR, EAL, " could not get VFIO API
version, "
- "error %i (%s)\n", errno,
strerror(errno));
- else
- RTE_LOG(ERR, EAL, " unsupported VFIO API
version!\n");
- close(vfio_container_fd);
- return -1;
- }
-
- ret = vfio_has_supported_extensions(vfio_container_fd);
- if (ret) {
- RTE_LOG(ERR, EAL, " no supported IOMMU "
- "extensions found!\n");
- return -1;
- }
-
- return vfio_container_fd;
- } else {
- /*
-* if we're in a secondary process, request container fd from
the
-* primary process via our socket
-*/
- int socket_fd;
-
- socket_fd = vfio_mp_sync_connect_to_primary();
- if (socket_fd < 0) {
- RTE_LOG(ERR, EAL, " cannot connect to primary
process!\n");
- return -1;
- }
- if (vfio_mp_sync_send_request(socket_fd, SOCKET_REQ_CONTAINER)
< 0) {
- RTE_LOG(ERR, EAL, " cannot request container fd!\n");
- close(socket_fd);
- return -1;
- }
- vfio_container_fd = vfio_mp_sync_receive_fd(socket_fd);
- if (vfio_container_fd < 0) {
- RTE_LOG(ERR, EAL, " cannot get container fd!\n");
- close(socket_fd);
- return -1;
- }
- close(socket_fd);
- return vfio_container_fd;
- }
-
- return -1;
-}
-
/* open group fd or get an existing one */
int
pci_vfio_get_group_fd(int iommu_group_no)
@@ -950,7 +885,7 @@ pci_vfio_enable(void)
return 0;
}
- vfio_cfg.vfio_container_fd = pci_vfio_get_container_fd();
+ vfio_cfg.vfio_container_fd = vfio_get_container_fd();
/* check if we have VFIO driver enabled */
if (vfio_cfg.vfio_container_fd != -1) {
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
index d54ded8..a759f02 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c
@@ -296,7 +296,7 @@ pci_vfio_mp_sync_thread(void __rte_unused * arg)
switch (ret) {
case SOCKET_REQ_CONT
[dpdk-dev] [PATCH v3 07/16] vfio: move vfio-specific SOCKET_* constants
The constants are not PCI-specific. Move them into the eal_vfio.h. Signed-off-by: Jan Viktorin --- lib/librte_eal/linuxapp/eal/eal_pci_init.h | 7 --- lib/librte_eal/linuxapp/eal/eal_vfio.h | 6 ++ 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_init.h b/lib/librte_eal/linuxapp/eal/eal_pci_init.h index 75b8ed3..883787f 100644 --- a/lib/librte_eal/linuxapp/eal/eal_pci_init.h +++ b/lib/librte_eal/linuxapp/eal/eal_pci_init.h @@ -97,13 +97,6 @@ int pci_vfio_map_resource(struct rte_pci_device *dev); int pci_vfio_get_group_fd(int iommu_group_fd); int pci_vfio_get_container_fd(void); -/* socket comm protocol definitions */ -#define SOCKET_REQ_CONTAINER 0x100 -#define SOCKET_REQ_GROUP 0x200 -#define SOCKET_OK 0x0 -#define SOCKET_NO_FD 0x1 -#define SOCKET_ERR 0xFF - #endif #endif /* EAL_PCI_INIT_H_ */ diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h b/lib/librte_eal/linuxapp/eal/eal_vfio.h index 8cb0d1d..121df0a 100644 --- a/lib/librte_eal/linuxapp/eal/eal_vfio.h +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h @@ -115,6 +115,12 @@ vfio_set_iommu_type(int vfio_container_fd); int vfio_has_supported_extensions(int vfio_container_fd); +#define SOCKET_REQ_CONTAINER 0x100 +#define SOCKET_REQ_GROUP 0x200 +#define SOCKET_OK 0x0 +#define SOCKET_NO_FD 0x1 +#define SOCKET_ERR 0xFF + int vfio_type1_dma_map(int); int vfio_noiommu_dma_map(int); -- 2.8.0
[dpdk-dev] [PATCH v3 06/16] vfio: generalize pci_vfio_has_supported_extensions
The pci_vfio_has_supported_extensions is not PCI-specific and it is a private
function of the eal_pci_vfio.c. We just rename the function and make it
available even for non-PCI devices.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 36 +-
lib/librte_eal/linuxapp/eal/eal_vfio.c | 33 +++
lib/librte_eal/linuxapp/eal/eal_vfio.h | 4
3 files changed, 38 insertions(+), 35 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 5fdf23f..f93db4a 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -203,40 +203,6 @@ pci_vfio_set_bus_master(int dev_fd)
return 0;
}
-/* check if we have any supported extensions */
-static int
-pci_vfio_has_supported_extensions(int vfio_container_fd) {
- int ret;
- unsigned idx, n_extensions = 0;
- for (idx = 0; idx < RTE_DIM(iommu_types); idx++) {
- const struct vfio_iommu_type *t = _types[idx];
-
- ret = ioctl(vfio_container_fd, VFIO_CHECK_EXTENSION,
- t->type_id);
- if (ret < 0) {
- RTE_LOG(ERR, EAL, " could not get IOMMU type, "
- "error %i (%s)\n", errno,
- strerror(errno));
- close(vfio_container_fd);
- return -1;
- } else if (ret == 1) {
- /* we found a supported extension */
- n_extensions++;
- }
- RTE_LOG(DEBUG, EAL, " IOMMU type %d (%s) is %s\n",
- t->type_id, t->name,
- ret ? "supported" : "not supported");
- }
-
- /* if we didn't find any supported IOMMU types, fail */
- if (!n_extensions) {
- close(vfio_container_fd);
- return -1;
- }
-
- return 0;
-}
-
/* set up interrupt support (but not enable interrupts) */
static int
pci_vfio_setup_interrupts(struct rte_pci_device *dev, int vfio_dev_fd)
@@ -360,7 +326,7 @@ pci_vfio_get_container_fd(void)
return -1;
}
- ret = pci_vfio_has_supported_extensions(vfio_container_fd);
+ ret = vfio_has_supported_extensions(vfio_container_fd);
if (ret) {
RTE_LOG(ERR, EAL, " no supported IOMMU "
"extensions found!\n");
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index ff85283..6a95d2a 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -62,6 +62,39 @@ vfio_set_iommu_type(int vfio_container_fd) {
}
int
+vfio_has_supported_extensions(int vfio_container_fd) {
+ int ret;
+ unsigned idx, n_extensions = 0;
+ for (idx = 0; idx < RTE_DIM(iommu_types); idx++) {
+ const struct vfio_iommu_type *t = _types[idx];
+
+ ret = ioctl(vfio_container_fd, VFIO_CHECK_EXTENSION,
+ t->type_id);
+ if (ret < 0) {
+ RTE_LOG(ERR, EAL, " could not get IOMMU type, "
+ "error %i (%s)\n", errno,
+ strerror(errno));
+ close(vfio_container_fd);
+ return -1;
+ } else if (ret == 1) {
+ /* we found a supported extension */
+ n_extensions++;
+ }
+ RTE_LOG(DEBUG, EAL, " IOMMU type %d (%s) is %s\n",
+ t->type_id, t->name,
+ ret ? "supported" : "not supported");
+ }
+
+ /* if we didn't find any supported IOMMU types, fail */
+ if (!n_extensions) {
+ close(vfio_container_fd);
+ return -1;
+ }
+
+ return 0;
+}
+
+int
vfio_type1_dma_map(int vfio_container_fd)
{
const struct rte_memseg *ms = rte_eal_get_physmem_layout();
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index afbb98a..8cb0d1d 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.h
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h
@@ -111,6 +111,10 @@ struct vfio_iommu_type {
const struct vfio_iommu_type *
vfio_set_iommu_type(int vfio_container_fd);
+/* check if we have any supported extensions */
+int
+vfio_has_supported_extensions(int vfio_container_fd);
+
int vfio_type1_dma_map(int);
int vfio_noiommu_dma_map(int);
--
2.8.0
[dpdk-dev] [PATCH v3 05/16] vfio: generalize pci_vfio_set_iommu_type
The pci_vfio_set_iommu_type is not PCI-specific and it is a private function
of the eal_pci_vfio.c. We just rename the function and make it available even
for non-PCI devices.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 25 +
lib/librte_eal/linuxapp/eal/eal_vfio.c | 22 ++
lib/librte_eal/linuxapp/eal/eal_vfio.h | 4
3 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index c52ea37..5fdf23f 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -203,29 +203,6 @@ pci_vfio_set_bus_master(int dev_fd)
return 0;
}
-/* pick IOMMU type. returns a pointer to vfio_iommu_type or NULL for error */
-static const struct vfio_iommu_type *
-pci_vfio_set_iommu_type(int vfio_container_fd) {
- unsigned idx;
- for (idx = 0; idx < RTE_DIM(iommu_types); idx++) {
- const struct vfio_iommu_type *t = _types[idx];
-
- int ret = ioctl(vfio_container_fd, VFIO_SET_IOMMU,
- t->type_id);
- if (!ret) {
- RTE_LOG(NOTICE, EAL, " using IOMMU type %d (%s)\n",
- t->type_id, t->name);
- return t;
- }
- /* not an error, there may be more supported IOMMU types */
- RTE_LOG(DEBUG, EAL, " set IOMMU type %d (%s) failed, "
- "error %i (%s)\n", t->type_id, t->name, errno,
- strerror(errno));
- }
- /* if we didn't find a suitable IOMMU type, fail */
- return NULL;
-}
-
/* check if we have any supported extensions */
static int
pci_vfio_has_supported_extensions(int vfio_container_fd) {
@@ -689,7 +666,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
vfio_cfg.vfio_container_has_dma == 0) {
/* select an IOMMU type which we will be using */
const struct vfio_iommu_type *t =
-
pci_vfio_set_iommu_type(vfio_cfg.vfio_container_fd);
+ vfio_set_iommu_type(vfio_cfg.vfio_container_fd);
if (!t) {
RTE_LOG(ERR, EAL, " %s failed to select IOMMU type\n",
pci_addr);
return -1;
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index d3ffebe..ff85283 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -39,6 +39,28 @@
#include "eal_vfio.h"
+const struct vfio_iommu_type *
+vfio_set_iommu_type(int vfio_container_fd) {
+ unsigned idx;
+ for (idx = 0; idx < RTE_DIM(iommu_types); idx++) {
+ const struct vfio_iommu_type *t = _types[idx];
+
+ int ret = ioctl(vfio_container_fd, VFIO_SET_IOMMU,
+ t->type_id);
+ if (!ret) {
+ RTE_LOG(NOTICE, EAL, " using IOMMU type %d (%s)\n",
+ t->type_id, t->name);
+ return t;
+ }
+ /* not an error, there may be more supported IOMMU types */
+ RTE_LOG(DEBUG, EAL, " set IOMMU type %d (%s) failed, "
+ "error %i (%s)\n", t->type_id, t->name, errno,
+ strerror(errno));
+ }
+ /* if we didn't find a suitable IOMMU type, fail */
+ return NULL;
+}
+
int
vfio_type1_dma_map(int vfio_container_fd)
{
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index c62f269..afbb98a 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.h
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h
@@ -107,6 +107,10 @@ struct vfio_iommu_type {
vfio_dma_func_t dma_map_func;
};
+/* pick IOMMU type. returns a pointer to vfio_iommu_type or NULL for error */
+const struct vfio_iommu_type *
+vfio_set_iommu_type(int vfio_container_fd);
+
int vfio_type1_dma_map(int);
int vfio_noiommu_dma_map(int);
--
2.8.0
[dpdk-dev] [PATCH v3 04/16] vfio: move vfio_iommu_type and dma_map functions to eal_vfio
We make the iommu_types public temporarily here until the depending stuff is
refactored. The iommu_types and dma_map functions will be changed to be private
inside the eal_vfio module later.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/Makefile | 1 +
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 62 ---
lib/librte_eal/linuxapp/eal/eal_vfio.c | 79 ++
lib/librte_eal/linuxapp/eal/eal_vfio.h | 23 +
4 files changed, 103 insertions(+), 62 deletions(-)
create mode 100644 lib/librte_eal/linuxapp/eal/eal_vfio.c
diff --git a/lib/librte_eal/linuxapp/eal/Makefile
b/lib/librte_eal/linuxapp/eal/Makefile
index 30b30f3..517554f 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -66,6 +66,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_xen_memory.c
endif
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_thread.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_log.c
+SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_vfio.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci_uio.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += eal_pci_vfio.c
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index c8f9ec1..c52ea37 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -72,68 +72,6 @@ EAL_REGISTER_TAILQ(rte_vfio_tailq)
/* per-process VFIO config */
static struct vfio_config vfio_cfg;
-/* DMA mapping function prototype.
- * Takes VFIO container fd as a parameter.
- * Returns 0 on success, -1 on error.
- * */
-typedef int (*vfio_dma_func_t)(int);
-
-struct vfio_iommu_type {
- int type_id;
- const char *name;
- vfio_dma_func_t dma_map_func;
-};
-
-static int vfio_type1_dma_map(int);
-static int vfio_noiommu_dma_map(int);
-
-/* IOMMU types we support */
-static const struct vfio_iommu_type iommu_types[] = {
- /* x86 IOMMU, otherwise known as type 1 */
- { RTE_VFIO_TYPE1, "Type 1", _type1_dma_map},
- /* IOMMU-less mode */
- { RTE_VFIO_NOIOMMU, "No-IOMMU", _noiommu_dma_map},
-};
-
-int
-vfio_type1_dma_map(int vfio_container_fd)
-{
- const struct rte_memseg *ms = rte_eal_get_physmem_layout();
- int i, ret;
-
- /* map all DPDK segments for DMA. use 1:1 PA to IOVA mapping */
- for (i = 0; i < RTE_MAX_MEMSEG; i++) {
- struct vfio_iommu_type1_dma_map dma_map;
-
- if (ms[i].addr == NULL)
- break;
-
- memset(_map, 0, sizeof(dma_map));
- dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map);
- dma_map.vaddr = ms[i].addr_64;
- dma_map.size = ms[i].len;
- dma_map.iova = ms[i].phys_addr;
- dma_map.flags = VFIO_DMA_MAP_FLAG_READ |
VFIO_DMA_MAP_FLAG_WRITE;
-
- ret = ioctl(vfio_container_fd, VFIO_IOMMU_MAP_DMA, _map);
-
- if (ret) {
- RTE_LOG(ERR, EAL, " cannot set up DMA remapping, "
- "error %i (%s)\n", errno,
strerror(errno));
- return -1;
- }
- }
-
- return 0;
-}
-
-int
-vfio_noiommu_dma_map(int __rte_unused vfio_container_fd)
-{
- /* No-IOMMU mode does not need DMA mapping */
- return 0;
-}
-
int
pci_vfio_read_config(const struct rte_intr_handle *intr_handle,
void *buf, size_t len, off_t offs)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_vfio.c
new file mode 100644
index 000..d3ffebe
--- /dev/null
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -0,0 +1,79 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DI
[dpdk-dev] [PATCH v3 03/16] vfio: move common vfio constants to eal_vfio.h
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 7 ---
lib/librte_eal/linuxapp/eal/eal_vfio.h | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 8b7d53f..c8f9ec1 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -69,13 +69,6 @@ static struct rte_tailq_elem rte_vfio_tailq = {
};
EAL_REGISTER_TAILQ(rte_vfio_tailq)
-#define VFIO_DIR "/dev/vfio"
-#define VFIO_CONTAINER_PATH "/dev/vfio/vfio"
-#define VFIO_GROUP_FMT "/dev/vfio/%u"
-#define VFIO_NOIOMMU_GROUP_FMT "/dev/vfio/noiommu-%u"
-#define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
-#define VFIO_GET_REGION_IDX(x) (x >> 40)
-
/* per-process VFIO config */
static struct vfio_config vfio_cfg;
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index cedbeb0..bcf6860 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.h
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h
@@ -88,6 +88,13 @@ struct vfio_config {
struct vfio_group vfio_groups[VFIO_MAX_GROUPS];
};
+#define VFIO_DIR "/dev/vfio"
+#define VFIO_CONTAINER_PATH "/dev/vfio/vfio"
+#define VFIO_GROUP_FMT "/dev/vfio/%u"
+#define VFIO_NOIOMMU_GROUP_FMT "/dev/vfio/noiommu-%u"
+#define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL)
+#define VFIO_GET_REGION_IDX(x) (x >> 40)
+
#define VFIO_PRESENT
#endif /* kernel version */
#endif /* RTE_EAL_VFIO */
--
2.8.0
[dpdk-dev] [PATCH v3 02/16] vfio: move VFIO-specific stuff to eal_vfio.h
The common VFIO definitions should be separated from the PCI-specific parts.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 28
lib/librte_eal/linuxapp/eal/eal_vfio.h | 28
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
index f72a254..75b8ed3 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_init.h
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_init.h
@@ -74,8 +74,6 @@ int pci_uio_ioport_unmap(struct rte_pci_ioport *p);
#ifdef VFIO_PRESENT
-#define VFIO_MAX_GROUPS 64
-
int pci_vfio_enable(void);
int pci_vfio_is_enabled(void);
int pci_vfio_mp_sync_setup(void);
@@ -99,15 +97,6 @@ int pci_vfio_map_resource(struct rte_pci_device *dev);
int pci_vfio_get_group_fd(int iommu_group_fd);
int pci_vfio_get_container_fd(void);
-/*
- * Function prototypes for VFIO multiprocess sync functions
- */
-int vfio_mp_sync_send_request(int socket, int req);
-int vfio_mp_sync_receive_request(int socket);
-int vfio_mp_sync_send_fd(int socket, int fd);
-int vfio_mp_sync_receive_fd(int socket);
-int vfio_mp_sync_connect_to_primary(void);
-
/* socket comm protocol definitions */
#define SOCKET_REQ_CONTAINER 0x100
#define SOCKET_REQ_GROUP 0x200
@@ -115,23 +104,6 @@ int vfio_mp_sync_connect_to_primary(void);
#define SOCKET_NO_FD 0x1
#define SOCKET_ERR 0xFF
-/*
- * we don't need to store device fd's anywhere since they can be obtained from
- * the group fd via an ioctl() call.
- */
-struct vfio_group {
- int group_no;
- int fd;
-};
-
-struct vfio_config {
- int vfio_enabled;
- int vfio_container_fd;
- int vfio_container_has_dma;
- int vfio_group_idx;
- struct vfio_group vfio_groups[VFIO_MAX_GROUPS];
-};
-
#endif
#endif /* EAL_PCI_INIT_H_ */
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index f483bf4..cedbeb0 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.h
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.h
@@ -60,6 +60,34 @@
#define RTE_VFIO_NOIOMMU VFIO_NOIOMMU_IOMMU
#endif
+#define VFIO_MAX_GROUPS 64
+
+/*
+ * Function prototypes for VFIO multiprocess sync functions
+ */
+int vfio_mp_sync_send_request(int socket, int req);
+int vfio_mp_sync_receive_request(int socket);
+int vfio_mp_sync_send_fd(int socket, int fd);
+int vfio_mp_sync_receive_fd(int socket);
+int vfio_mp_sync_connect_to_primary(void);
+
+/*
+ * we don't need to store device fd's anywhere since they can be obtained from
+ * the group fd via an ioctl() call.
+ */
+struct vfio_group {
+ int group_no;
+ int fd;
+};
+
+struct vfio_config {
+ int vfio_enabled;
+ int vfio_container_fd;
+ int vfio_container_has_dma;
+ int vfio_group_idx;
+ struct vfio_group vfio_groups[VFIO_MAX_GROUPS];
+};
+
#define VFIO_PRESENT
#endif /* kernel version */
#endif /* RTE_EAL_VFIO */
--
2.8.0
[dpdk-dev] [PATCH v3 01/16] vfio: fix include of eal_private.h to be local
Signed-off-by: Jan Viktorin --- lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c index f91b924..8b7d53f 100644 --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c @@ -43,11 +43,11 @@ #include #include #include -#include #include "eal_filesystem.h" #include "eal_pci_init.h" #include "eal_vfio.h" +#include "eal_private.h" /** * @file -- 2.8.0
[dpdk-dev] [PATCH v3 00/16] Make VFIO support less dependent on PCI
Hello,
I've rebased the v2 of this patch set on top of the current master.
It builds well for my setup (both VFIO enabled and disabled).
Regards
Jan
v3:
* 0012: Acked-by: John McNamara
Jan Viktorin (16):
vfio: fix include of eal_private.h to be local
vfio: move VFIO-specific stuff to eal_vfio.h
vfio: move common vfio constants to eal_vfio.h
vfio: move vfio_iommu_type and dma_map functions to eal_vfio
vfio: generalize pci_vfio_set_iommu_type
vfio: generalize pci_vfio_has_supported_extensions
vfio: move vfio-specific SOCKET_* constants
vfio: generalize pci_vfio_get_container_fd
vfio: generalize pci_vfio_get_group_no
vfio: extract setup logic out of pci_vfio_map_resource
vfio: move global vfio_cfg to eal_vfio.c
vfio: fix typo in doc for vfio_setup_device
vfio: make vfio_*_dma_map and iommu_types private
vfio: rename and generalize eal_pci_vfio_mp_sync
vfio: initialize vfio out of the PCI subsystem
vfio: change VFIO init to be extendable
lib/librte_eal/linuxapp/eal/Makefile | 5 +-
lib/librte_eal/linuxapp/eal/eal.c | 33 ++
lib/librte_eal/linuxapp/eal/eal_pci.c | 17 +-
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 41 --
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 517 +--
lib/librte_eal/linuxapp/eal/eal_vfio.c | 547 +
lib/librte_eal/linuxapp/eal/eal_vfio.h | 94
.../{eal_pci_vfio_mp_sync.c => eal_vfio_mp_sync.c} | 12 +-
8 files changed, 691 insertions(+), 575 deletions(-)
create mode 100644 lib/librte_eal/linuxapp/eal/eal_vfio.c
rename lib/librte_eal/linuxapp/eal/{eal_pci_vfio_mp_sync.c =>
eal_vfio_mp_sync.c} (97%)
--
2.8.0
[dpdk-dev] [PATCH v2 01/16] vfio: fix include of eal_private.h to be local
On Mon, 4 Jul 2016 10:22:08 + "Burakov, Anatoly" wrote: [...] > There's no patch cover letter so I'll reply to the first patch. I've done > some cursory testing with a NIC, nothing seems to be broken and the code > looks OK to me. So, once this patchset is rebased on latest master (patches > 9, 14 and 15 no longer apply cleanly), ack from me. I am going to post v3. Should I include the ACKs on all patches or will you post them yourself? Jan > > Thanks, > Anatoly
[dpdk-dev] [PATCH v1 28/28] ether: support SoC device/driver
On Mon, 4 Jul 2016 19:57:18 +0530 Shreyansh jain wrote: [...] > >>> @@ -1431,7 +1524,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct > >>> rte_eth_dev_info *dev_info) > >>> > >>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get); > >>> (*dev->dev_ops->dev_infos_get)(dev, dev_info); > >>> - dev_info->pci_dev = dev->pci_dev; > >>> + dev_info->soc_dev = dev->soc_dev; > >> > >> I think both the members, pci_dev and soc_dev, should be updated by this > >> call. > >> Is there some specific reason why soc_dev is the only one which is getting > >> updated? > > > > Yes, looks like a mistake. Thanks! And sorry for delayed reply. > > No problems - thanks for confirmation. > I have gone through almost complete series and as and when you rebase it, it > would have my ACK. OK, thanks. That's what I am playing with right now. I've rebased on v3 of this patch. There will be some more tests in my v2. > rte_driver patchset which I sent last are broken - I will publish an updated > version very soon. I am surprised that you've changed the args to RTE_EAL_PCI_REGISTER... Are you sure about this step? I wrote that I'll change it myself for v2 for SoC to accept name and pointer as it was originally for PCI... Jan
[dpdk-dev] [PATCH v1 02/28] eal: extract function eal_parse_sysfs_valuef
Hello Shreyansh, On Thu, 16 Jun 2016 11:47:29 + Shreyansh Jain wrote: > Sorry, didn't notice this email earlier... > Comments inline > > > -Original Message----- > > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > > Sent: Wednesday, June 15, 2016 3:26 PM > > To: Shreyansh Jain > > Cc: dev at dpdk.org; David Marchand ; Thomas > > Monjalon > > ; Bruce Richardson > intel.com>; > > Declan Doherty ; jianbo.liu at linaro.org; > > jerin.jacob at caviumnetworks.com; Keith Wiles ; > > Stephen > > Hemminger > > Subject: Re: [dpdk-dev] [PATCH v1 02/28] eal: extract function > > eal_parse_sysfs_valuef > > > > On Tue, 14 Jun 2016 04:30:57 + > > Shreyansh Jain wrote: > > > > > Hi Jan, > > > > > [...] > > > > > > > > > > > > I almost skipped the '..f' in the name and wondered how two functions > > > > > > > > > having same name exist :D > > > > > > > > I agree that a better name would be nice here. This convention was > > > > based > > on > > > > the libc naming > > > > (fopen, fclose) but the "f" letter could not be at the beginning. > > > > > > > > What about one of those? > > > > > > > > * eal_parse_sysfs_fd_value > > > > * eal_parse_sysfs_file_value > > > > > > I don't have any better idea than above. > > > > > > Though, I still feel that 'eal_parse_sysfs_value -> > > eal_parse_sysfs_file_value' would be slightly asymmetrical - but again, this > > is highly subjective argument. > > > > I don't see any asymmetry here. The functions equal, just the new one > > accepts > > a file pointer instead of a path > > and we don't have function name overloading in C. > > Asymmetrical because cascading function names maybe additive for easy > reading/recall. > > 'eal_parse_sysfs_value ==> eal_parse_sysfs_value_ ==> > eal_parse_sysfs_value__' > > Obviously, this is not a rule - it just makes reading and recalling of > cascade easier. > As for: > > eal_parse_sysfs_value => eal_parse_sysfs_file_value > > inserts an identifier between a name, making it (slightly) difficult to > correlate. > > Again, as I mentioned earlier, this is subjective argument and matter of > (personal!) choice. > > > > > > > > > Or, eal_parse_sysfs_value -> eal_parse_sysfs_value_read() may be... > > > > I think, I'll go with eal_parse_sysfs_file_value for v2. Ideally, it should > > be > > eal_parse_sysfs_path_value and eal_parse_sysfs_file_value. Thus, this looks > > like > > a good way. > > > > > > > > But, eal_parse_sysfs_file_value is still preferred than > > eal_parse_sysfs_fd_value, for me. > > > > Agree. > > > [...] I've finally returned to your idea to name it eal_parse_sysfs_value_read. Thanks. Jan > > - > Shreyansh -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v1 28/28] ether: support SoC device/driver
On Wed, 29 Jun 2016 15:12:07 +0530
Shreyansh jain wrote:
> Hi Jan,
>
> On Friday 06 May 2016 07:18 PM, Jan Viktorin wrote:
> > Signed-off-by: Jan Viktorin
> > ---
> > lib/librte_ether/rte_ethdev.c | 127
> > +-
> > lib/librte_ether/rte_ethdev.h | 31 +++
> > 2 files changed, 157 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> > index 4af2e5f..9259c2c 100644
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -320,6 +320,99 @@ rte_eth_dev_pci_remove(struct rte_pci_device *pci_dev)
> > }
> >
> [...]
> > +int
> > rte_eth_dev_is_valid_port(uint8_t port_id)
> > {
> > if (port_id >= RTE_MAX_ETHPORTS ||
> > @@ -1431,7 +1524,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct
> > rte_eth_dev_info *dev_info)
> >
> > RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
> > (*dev->dev_ops->dev_infos_get)(dev, dev_info);
> > - dev_info->pci_dev = dev->pci_dev;
> > + dev_info->soc_dev = dev->soc_dev;
>
> I think both the members, pci_dev and soc_dev, should be updated by this call.
> Is there some specific reason why soc_dev is the only one which is getting
> updated?
Yes, looks like a mistake. Thanks! And sorry for delayed reply.
Jan
>
> > dev_info->driver_name = dev->data->drv_name;
> > }
> >
> [...]
>
> -
> Shreyansh
>
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v2 01/16] vfio: fix include of eal_private.h to be local
On Mon, 4 Jul 2016 10:22:08 + "Burakov, Anatoly" wrote: > > -Original Message----- > > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > > Sent: Monday, June 13, 2016 2:02 PM > > To: dev at dpdk.org > > Cc: Jan Viktorin ; Burakov, Anatoly > > ; David Marchand > > ; Wiles, Keith ; > > Santosh Shukla ; Stephen Hemminger > > ; Shreyansh Jain > > > > Subject: [PATCH v2 01/16] vfio: fix include of eal_private.h to be local > > > > Signed-off-by: Jan Viktorin > > --- > > lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c > > b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c > > index 10266f8..257162b 100644 > > --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c > > +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c > > @@ -43,11 +43,11 @@ > > #include > > #include > > #include > > -#include > > > > #include "eal_filesystem.h" > > #include "eal_pci_init.h" > > #include "eal_vfio.h" > > +#include "eal_private.h" > > > > /** > > * @file > > -- > > 2.8.0 > Hello Anatoly, > There's no patch cover letter so I'll reply to the first patch. yes, there is (and you are in CC), may be lost in the traffic... http://dpdk.org/ml/archives/dev/2016-June/041085.html ID: 1465822926-23742-1-git-send-email-viktorin at rehivetech.com > I've done some cursory testing with a NIC, nothing seems to be broken and the > code looks OK to me. So, once this patchset is rebased on latest master > (patches 9, 14 and 15 no longer apply cleanly), ack from me. Thank you very much! I am going to do the rebase. Jan > > Thanks, > Anatoly -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v16 0/3] mempool: add mempool handler feature
On Fri, 24 Jun 2016 13:24:56 +0200 Thomas Monjalon wrote: > 2016-06-24 13:20, Jan Viktorin: > > thanks for the patchset. I am sorry, I didn't have any time for DPDK this > > week > > and didn't test it before applying. The current master produces the > > following > > error in my regular builds: > > > > INSTALL-LIB librte_eal.a > > == Build lib/librte_ring > > CC rte_ring.o > > AR librte_ring.a > > SYMLINK-FILE include/rte_ring.h > > INSTALL-LIB librte_ring.a > > == Build lib/librte_mempool > > CC rte_mempool.o > > make[3]: *** No rule to make target `rte_mempool_ops.o', needed by > > `librte_mempool.a'. Stop. > > It should be fixed now. OK, confirmed. It seems that I only receive notifications of failures :). Jan
[dpdk-dev] [PATCH v16 0/3] mempool: add mempool handler feature
On Fri, 24 Jun 2016 04:55:39 + "Wiles, Keith" wrote: > On 6/23/16, 11:22 PM, "dev on behalf of Thomas Monjalon" dpdk.org on behalf of thomas.monjalon at 6wind.com> wrote: > > >> David Hunt (2): > >> mempool: support mempool handler operations > >> app/test: test mempool handler > >> mbuf: make default mempool ops configurable at build > > > >Applied, thanks for the nice feature > > > >I'm sorry David, the revision record is v17 ;) > > Quick David, make two more updates to the patch ? > > Thanks David and Great work !!! > > > > > Hello David, thanks for the patchset. I am sorry, I didn't have any time for DPDK this week and didn't test it before applying. The current master produces the following error in my regular builds: INSTALL-LIB librte_eal.a == Build lib/librte_ring CC rte_ring.o AR librte_ring.a SYMLINK-FILE include/rte_ring.h INSTALL-LIB librte_ring.a == Build lib/librte_mempool CC rte_mempool.o make[3]: *** No rule to make target `rte_mempool_ops.o', needed by `librte_mempool.a'. Stop. make[2]: *** [librte_mempool] Error 2 make[1]: *** [lib] Error 2 make: *** [all] Error 2 Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE I have no idea about the reason at the moment. I'll check it soon. Regards Jan
[dpdk-dev] [PATCH v14 3/3] mbuf: make default mempool ops configurable at build
On Fri, 17 Jun 2016 14:53:38 +0100 David Hunt wrote: > By default, the mempool ops used for mbuf allocations is a multi > producer and multi consumer ring. We could imagine a target (maybe some > network processors?) that provides an hardware-assisted pool > mechanism. In this case, the default configuration for this architecture > would contain a different value for RTE_MBUF_DEFAULT_MEMPOOL_OPS. > > Signed-off-by: Olivier Matz > Signed-off-by: David Hunt > Acked-by: Shreyansh Jain > Acked-by: Olivier Matz > --- Reviewed-by: Jan Viktorin
[dpdk-dev] [PATCH v14 2/3] app/test: test mempool handler
On Fri, 17 Jun 2016 14:53:37 +0100 David Hunt wrote: > Create a minimal custom mempool handler and check that it > passes basic mempool autotests. > > Signed-off-by: Olivier Matz > Signed-off-by: David Hunt > Acked-by: Shreyansh Jain > Acked-by: Olivier Matz > --- Reviewed-by: Jan Viktorin
[dpdk-dev] [PATCH v14 1/3] mempool: support mempool handler operations
Hi David,
still few nits... Do you like the upstreaming process? :) I hope finish this
patchset soon. The major issues seem to be OK.
[...]
> +
> +/**
> + * @internal Get the mempool ops struct from its index.
> + *
> + * @param ops_index
> + * The index of the ops struct in the ops struct table. It must be a valid
> + * index: (0 <= idx < num_ops).
> + * @return
> + * The pointer to the ops struct in the table.
> + */
> +static inline struct rte_mempool_ops *
> +rte_mempool_ops_get(int ops_index)
What about to rename the ops_get to get_ops to not confuse
with the ops wrappers? The thread on this topic has not
been finished. I think, we can live with this name, it's
just a bit weird...
Olivier? Thomas?
> +{
> + RTE_VERIFY(ops_index < RTE_MEMPOOL_MAX_OPS_IDX);
According to the doc comment:
RTE_VERIFY(ops_index >= 0);
> +
> + return _mempool_ops_table.ops[ops_index];
> +}
[...]
> +
> +/**
> + * @internal Wrapper for mempool_ops get callback.
This comment is obsolete "get callback" vs. dequeue_bulk.
> + *
> + * @param mp
> + * Pointer to the memory pool.
> + * @param obj_table
> + * Pointer to a table of void * pointers (objects).
> + * @param n
> + * Number of objects to get.
> + * @return
> + * - 0: Success; got n objects.
> + * - <0: Error; code of get function.
"get function" seems to be obsolete, too...
> + */
> +static inline int
> +rte_mempool_ops_dequeue_bulk(struct rte_mempool *mp,
> + void **obj_table, unsigned n)
> +{
> + struct rte_mempool_ops *ops;
> +
> + ops = rte_mempool_ops_get(mp->ops_index);
> + return ops->dequeue(mp, obj_table, n);
> +}
> +
> +/**
> + * @internal wrapper for mempool_ops put callback.
similar: "put callback"
> + *
> + * @param mp
> + * Pointer to the memory pool.
> + * @param obj_table
> + * Pointer to a table of void * pointers (objects).
> + * @param n
> + * Number of objects to put.
> + * @return
> + * - 0: Success; n objects supplied.
> + * - <0: Error; code of put function.
similar: "put function"
> + */
> +static inline int
> +rte_mempool_ops_enqueue_bulk(struct rte_mempool *mp, void * const *obj_table,
> + unsigned n)
> +{
> + struct rte_mempool_ops *ops;
> +
> + ops = rte_mempool_ops_get(mp->ops_index);
> + return ops->enqueue(mp, obj_table, n);
> +}
> +
[...]
> +
> +/* add a new ops struct in rte_mempool_ops_table, return its index. */
> +int
> +rte_mempool_ops_register(const struct rte_mempool_ops *h)
> +{
> + struct rte_mempool_ops *ops;
> + int16_t ops_index;
> +
> + rte_spinlock_lock(_mempool_ops_table.sl);
> +
> + if (rte_mempool_ops_table.num_ops >=
> + RTE_MEMPOOL_MAX_OPS_IDX) {
> + rte_spinlock_unlock(_mempool_ops_table.sl);
> + RTE_LOG(ERR, MEMPOOL,
> + "Maximum number of mempool ops structs exceeded\n");
> + return -ENOSPC;
> + }
> +
> + if (h->alloc == NULL || h->enqueue == NULL ||
> + h->dequeue == NULL || h->get_count == NULL) {
> + rte_spinlock_unlock(_mempool_ops_table.sl);
> + RTE_LOG(ERR, MEMPOOL,
> + "Missing callback while registering mempool ops\n");
> + return -EINVAL;
> + }
> +
> + if (strlen(h->name) >= sizeof(ops->name) - 1) {
> + RTE_LOG(DEBUG, EAL, "%s(): mempool_ops <%s>: name too long\n",
> + __func__, h->name);
The unlock is missing here, isn't?
> + rte_errno = EEXIST;
> + return -EEXIST;
> + }
> +
> + ops_index = rte_mempool_ops_table.num_ops++;
> + ops = _mempool_ops_table.ops[ops_index];
> + snprintf(ops->name, sizeof(ops->name), "%s", h->name);
> + ops->alloc = h->alloc;
> + ops->enqueue = h->enqueue;
> + ops->dequeue = h->dequeue;
> + ops->get_count = h->get_count;
> +
> + rte_spinlock_unlock(_mempool_ops_table.sl);
> +
> + return ops_index;
> +}
> +
> +/* wrapper to allocate an external mempool's private (pool) data. */
> +int
> +rte_mempool_ops_alloc(struct rte_mempool *mp)
> +{
> + struct rte_mempool_ops *ops;
> +
> + ops = rte_mempool_ops_get(mp->ops_index);
> + return ops->alloc(mp);
> +}
> +
> +/* wrapper to free an external pool ops. */
> +void
> +rte_mempool_ops_free(struct rte_mempool *mp)
> +{
> + struct rte_mempool_ops *ops;
> +
> + ops = rte_mempool_ops_get(mp->ops_index);
I assume there would never be an rte_mempool_ops_unregister. Otherwise this
function can
return NULL and may lead to a NULL pointer exception.
> + if (ops->free == NULL)
> + return;
> + return ops->free(mp);
This return statement here is redundant (void).
> +}
> +
> +/* wrapper to get available objects in an external mempool. */
> +unsigned int
> +rte_mempool_ops_get_count(const struct rte_mempool *mp)
[...]
Regards
Jan
[dpdk-dev] [PATCH] app/test: call objdump in platform-independent way
Using of the /dev/stdin generates a warning when compiling on FreeBSD: objcopy: Warning: '/dev/stdin' is not an ordinary file app/test/Makefile:78: recipe for target 'test_resource_c.res.o' failed # ls -l /dev/stdin lrwxr-xr-x 1 root wheel 4 Jun 17 12:24 /dev/stdin -> fd/0 Replace /dev/stdin by a temporary file. Signed-off-by: Jan Viktorin Reported-by: Thomas Monjalon --- app/test/Makefile | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/app/test/Makefile b/app/test/Makefile index 5e3ebdc..36ff089 100644 --- a/app/test/Makefile +++ b/app/test/Makefile @@ -43,13 +43,14 @@ define linked_resource SRCS-y += $(1).res.o $(1).res.o: $(2) @ echo ' MKRES $$@' + $Q ln -fs $$< resource.tmp $Q $(OBJCOPY) -I binary -B $(RTE_OBJCOPY_ARCH) -O $(RTE_OBJCOPY_TARGET) \ --rename-section \ .data=.rodata,alloc,load,data,contents,readonly \ - --redefine-sym _binary__dev_stdin_start=beg_$(1) \ - --redefine-sym _binary__dev_stdin_end=end_$(1) \ - --redefine-sym _binary__dev_stdin_size=siz_$(1) \ - /dev/stdin $$@ < $$< + --redefine-sym _binary_resource_tmp_start=beg_$(1) \ + --redefine-sym _binary_resource_tmp_end=end_$(1) \ + --redefine-sym _binary_resource_tmp_size=siz_$(1)\ + resource.tmp $$@ && rm -f resource.tmp endef ifeq ($(CONFIG_RTE_APP_TEST_RESOURCE_TAR),y) -- 2.8.0
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
On Thu, 16 Jun 2016 08:42:29 + Shreyansh Jain wrote: > Hi, > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Thursday, June 16, 2016 1:04 PM > > To: Shreyansh Jain > > Cc: David Marchand ; viktorin at > > rehivetech.com; > > dev at dpdk.org; Iremonger, Bernard > > Subject: Re: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver > > > > 2016-06-16 06:32, Shreyansh Jain: > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, > > > Bernard > > > > Patches 3,8,16 and 17 no longer apply to the latest master branch. > > > > A rebase is needed. > > > > > > With the recent most head (04920e6): 01, 03, 08, 15, 16 and 17 are > > > failing. > > > > > > Just wanted to check if there is a rebase of this series anytime soon? > > > > I will take care of this series if time permit. > > Ok. > By the way, I have already rebased it on master. I can post the patches here > if you want. > (only trivial conflicts were there) Sounds good. +1 I'd rebase my patchset on top of it and repost. > > > It would help to have more reviews on other series touching EAL, like > > pmdinfo. > > Ok. I can try and review this, non-PCI/SoC and similar patchset in next few > days. The original David's patchset was quite OK. I didn't have any comments. The thing is (from my POV) that it was incomplete. Jan > > > > > > I was looking at Jan's non-PCI patchset [1] and they are based on this > > series. > > > > > > [1] > > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/30913/focus=38486 > > - > Shreyansh >
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
On Thu, 16 Jun 2016 11:19:59 +0200 Thomas Monjalon wrote: > 2016-06-16 10:23, Jan Viktorin: > > I think, we should consider to move it to somebody else. I would work on > > it, however, I don't see all the tasks that are to be done. That's why I > > was waiting to finalize those patchs by David or Thomas. For me, the > > important things were to generalize certain things to remove dependency on > > PCI. This is mostly done (otherwise the SoC patchset couldn't be done in > > the way I've posted it). > > > > Now, there is some pending work to remove pmd_type. Next, to find out some > > generalization of rte_pci_device/driver to create rte_device/driver (I've > > posted several suggestions in the of SoC patchset). For the pmd_type removal, I am not very sure about the original David's intentions. What should be the result? Should there be a special struct rte_virt_device or something like that? > > > > What more? > > We need a clean devargs API in EAL, not directly related to hotplug. > Then the hotplug can benefit of the devargs API as any other device config. Do we have some requirements for this? Would it be a complete redefinition of the API? I don't see the relations to hotplug. > > The EAL resources (also called devices) need an unique naming convention. > No idea about this. What do you mean by the unique naming convention? Jan
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
I think, we should consider to move it to somebody else. I would work on it, however, I don't see all the tasks that are to be done. That's why I was waiting to finalize those patchs by David or Thomas. For me, the important things were to generalize certain things to remove dependency on PCI. This is mostly done (otherwise the SoC patchset couldn't be done in the way I've posted it). Now, there is some pending work to remove pmd_type. Next, to find out some generalization of rte_pci_device/driver to create rte_device/driver (I've posted several suggestions in the of SoC patchset). What more? Jan?Viktorin RehiveTech Sent?from?a?mobile?device ? P?vodn? zpr?va ? Od: Thomas Monjalon Odesl?no: ?tvrtek, 16. ?ervna 2016 9:34 Komu: Shreyansh Jain Kopie: David Marchand; viktorin at rehivetech.com; dev at dpdk.org; Iremonger, Bernard P?edm?t: Re: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver 2016-06-16 06:32, Shreyansh Jain: > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, Bernard > > Patches 3,8,16 and 17 no longer apply to the latest master branch. > > A rebase is needed. > > With the recent most head (04920e6): 01, 03, 08, 15, 16 and 17 are failing. > > Just wanted to check if there is a rebase of this series anytime soon? I will take care of this series if time permit. It would help to have more reviews on other series touching EAL, like pmdinfo. > I was looking at Jan's non-PCI patchset [1] and they are based on this series. > > [1] http://thread.gmane.org/gmane.comp.networking.dpdk.devel/30913/focus=38486
[dpdk-dev] [PATCH v12 0/3] mempool: add external mempool manager
On Wed, 15 Jun 2016 16:10:13 +0200
Olivier MATZ wrote:
> On 06/15/2016 04:02 PM, Hunt, David wrote:
> >
> >
> > On 15/6/2016 2:50 PM, Olivier MATZ wrote:
> >> Hi David,
> >>
> >> On 06/15/2016 02:38 PM, Hunt, David wrote:
> >>>
> >>>
> >>> On 15/6/2016 1:03 PM, Olivier MATZ wrote:
> >>>> Hi,
> >>>>
> >>>> On 06/15/2016 01:47 PM, Hunt, David wrote:
> >>>>>
> >>>>>
> >>>>> On 15/6/2016 11:13 AM, Jan Viktorin wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I've got one last question. Initially, I was interested in creating
> >>>>>> my own external memory provider based on a Linux Kernel driver.
> >>>>>> So, I've got an opened file descriptor that points to a device which
> >>>>>> can mmap a memory regions for me.
> >>>>>>
> >>>>>> ...
> >>>>>> int fd = open("/dev/uio0" ...);
> >>>>>> ...
> >>>>>> rte_mempool *pool = rte_mempool_create_empty(...);
> >>>>>> rte_mempool_set_ops_byname(pool, "uio_allocator_ops");
> >>>>>>
> >>>>>> I am not sure how to pass the file descriptor pointer. I thought it
> >>>>>> would
> >>>>>> be possible by the rte_mempool_alloc but it's not... Is it possible
> >>>>>> to solve this case?
> >>>>>>
> >>>>>> The allocator is device-specific.
> >>>>>>
> >>>>>> Regards
> >>>>>> Jan
> >>>>>
> >>>>> This particular use case is not covered.
> >>>>>
> >>>>> We did discuss this before, and an opaque pointer was proposed, but
> >>>>> did
> >>>>> not make it in.
> >>>>> http://article.gmane.org/gmane.comp.networking.dpdk.devel/39821
> >>>>> (and following emails in that thread)
> >>>>>
> >>>>> So, the options for this use case are as follows:
> >>>>> 1. Use the pool_data to pass data in to the alloc, then set the
> >>>>> pool_data pointer before coming back from alloc. (It's a bit of a
> >>>>> hack,
> >>>>> but means no code change).
> >>>>> 2. Add an extra parameter to the alloc function. The simplest way I
> >>>>> can
> >>>>> think of doing this is to
> >>>>> take the *opaque passed into rte_mempool_populate_phys, and pass it on
> >>>>> into the alloc function.
> >>>>> This will have minimal impact on the public API,s as there is
> >>>>> already an
> >>>>> opaque there in the _populate_ funcs, we're just
> >>>>> reusing it for the alloc.
> >>>>>
> >>>>> Do others think option 2 is OK to add this at this late stage? Even if
> >>>>> the patch set has already been ACK'd?
> >>>>
> >>>> Jan's use-case looks to be relevant.
> >>>>
> >>>> What about changing:
> >>>>
> >>>> rte_mempool_set_ops_byname(struct rte_mempool *mp, const char *name)
> >>>>
> >>>> into:
> >>>>
> >>>> rte_mempool_set_ops(struct rte_mempool *mp, const char *name,
> >>>> void *opaque)
Or a third function?
rte_mempool_set_ops_arg(struct rte_mempool, *mp, void *arg)
Or isn't it really a task for a kind of rte_mempool_populate_*?
This is a part of mempool I am not involved in yet.
> >>>>
> >>>> ?
> >>>>
> >>>> The opaque pointer would be saved in mempool structure, and used
> >>>> when the mempool is populated (calling mempool_ops_alloc).
> >>>> The type of the structure pointed by the opaque has to be defined
> >>>> (and documented) into each mempool_ops manager.
> >>>>
> >>>
> >>> Yes, that was another option, which has the additional impact of
> >>> needing an
> >>> opaque added to the mempool struct. If we use the opaque from the
> >>> _populate_
> >>> function, we use it straight away in the alloc, no storage needed.
> >>>
> >>> Also, do you think we need to go ahead with this change, or can we add
> >>> it la
[dpdk-dev] [PATCH v12 1/3] mempool: support external mempool operations
On Wed, 15 Jun 2016 11:29:51 +0100 "Hunt, David" wrote: > On 15/6/2016 11:14 AM, Jan Viktorin wrote: > > On Wed, 15 Jun 2016 08:47:02 +0100 > > David Hunt wrote: > > > > [...] > > > > >> + > >> +/** Array of registered ops structs. */ > >> +extern struct rte_mempool_ops_table rte_mempool_ops_table; > >> + > >> +/** > >> + * @internal Get the mempool ops struct from its index. > >> + * > >> + * @param ops_index > >> + * The index of the ops struct in the ops struct table. It must be a > >> valid > >> + * index: (0 <= idx < num_ops). > >> + * @return > >> + * The pointer to the ops struct in the table. > >> + */ > >> +static inline struct rte_mempool_ops * > >> +rte_mempool_ops_get(int ops_index) > > Shouldn't this function be called rte_mempool_get/find_ops instead? > > > > > > Jan, > > I think at this stage that it's probably OK as it is. :) Ok. I just remember some discussion about this. I didn't follow the thread during last days so I wanted to be sure that it's not forgotten. Jan > > Rgds, > Dave. > > > > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v12 1/3] mempool: support external mempool operations
On Wed, 15 Jun 2016 08:47:02 +0100
David Hunt wrote:
> Until now, the objects stored in a mempool were internally stored in a
> ring. This patch introduces the possibility to register external handlers
> replacing the ring.
>
> The default behavior remains unchanged, but calling the new function
> rte_mempool_set_ops_byname() right after rte_mempool_create_empty() allows
> the user to change the handler that will be used when populating
> the mempool.
>
> This patch also adds a set of default ops (function callbacks) based
> on rte_ring.
>
> Signed-off-by: Olivier Matz
> Signed-off-by: David Hunt
> Acked-by: Shreyansh Jain
> Acked-by: Olivier Matz
> ---
> app/test/test_mempool_perf.c | 1 -
> doc/guides/prog_guide/mempool_lib.rst | 31 +++-
> doc/guides/rel_notes/deprecation.rst | 9 --
> lib/librte_mempool/Makefile| 2 +
> lib/librte_mempool/rte_mempool.c | 66 +++-
> lib/librte_mempool/rte_mempool.h | 251
> ++---
> lib/librte_mempool/rte_mempool_ops.c | 148 +
> lib/librte_mempool/rte_mempool_ring.c | 161 ++
> lib/librte_mempool/rte_mempool_version.map | 13 +-
> 9 files changed, 601 insertions(+), 81 deletions(-)
> create mode 100644 lib/librte_mempool/rte_mempool_ops.c
> create mode 100644 lib/librte_mempool/rte_mempool_ring.c
>
[...]
> +
> +/** Array of registered ops structs. */
> +extern struct rte_mempool_ops_table rte_mempool_ops_table;
> +
> +/**
> + * @internal Get the mempool ops struct from its index.
> + *
> + * @param ops_index
> + * The index of the ops struct in the ops struct table. It must be a valid
> + * index: (0 <= idx < num_ops).
> + * @return
> + * The pointer to the ops struct in the table.
> + */
> +static inline struct rte_mempool_ops *
> +rte_mempool_ops_get(int ops_index)
Shouldn't this function be called rte_mempool_get/find_ops instead?
Jan
> +{
> + RTE_VERIFY(ops_index < RTE_MEMPOOL_MAX_OPS_IDX);
> +
> + return _mempool_ops_table.ops[ops_index];
> +}
> +
[dpdk-dev] [PATCH v12 0/3] mempool: add external mempool manager
which is then stored in the rte_memool structure. This
> allow multiple processes to use the same mempool, as the function pointers
> are accessed via ops index.
>
> The mempool ops structure contains callbacks to the implementation of
> the ops function, and is set up for registration as follows:
>
> static const struct rte_mempool_ops ops_sp_mc = {
> .name = "ring_sp_mc",
> .alloc = rte_mempool_common_ring_alloc,
> .enqueue = common_ring_sp_enqueue,
> .dequeue = common_ring_mc_dequeue,
> .get_count = common_ring_get_count,
> .free = common_ring_free,
> };
>
> And then the following macro will register the ops in the array of ops
> structures
>
> REGISTER_MEMPOOL_OPS(ops_mp_mc);
>
> For an example of API usage, please see app/test/test_mempool.c, which
> implements a rudimentary "custom_handler" mempool manager using simple mallocs
> for each mempool object. This file also contains the callbacks and self
> registration for the new handler.
>
> David Hunt (2):
> mempool: support external mempool operations
> mbuf: make default mempool ops configurable at build
>
> Olivier Matz (1):
> app/test: test external mempool manager
>
>
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v1 02/28] eal: extract function eal_parse_sysfs_valuef
On Tue, 14 Jun 2016 04:30:57 +
Shreyansh Jain wrote:
> Hi Jan,
>
> > -Original Message-
> > From: Jan Viktorin [mailto:viktorin at rehivetech.com]
> > Sent: Monday, June 13, 2016 7:55 PM
> > To: Shreyansh Jain
> > Cc: dev at dpdk.org; David Marchand ; Thomas
> > Monjalon
> > ; Bruce Richardson > intel.com>;
> > Declan Doherty ; jianbo.liu at linaro.org;
> > jerin.jacob at caviumnetworks.com; Keith Wiles ;
> > Stephen
> > Hemminger
> > Subject: Re: [dpdk-dev] [PATCH v1 02/28] eal: extract function
> > eal_parse_sysfs_valuef
> >
> > On Mon, 13 Jun 2016 14:18:40 +
> > Shreyansh Jain wrote:
> >
> > > Hi Jan,
> > >
> > > > -Original Message-
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jan Viktorin
> > > > Sent: Friday, May 06, 2016 7:18 PM
> > > > To: dev at dpdk.org
> > > > Cc: Jan Viktorin ; David Marchand
> > > > ; Thomas Monjalon > > > 6wind.com>;
> > > > Bruce Richardson ; Declan Doherty
> > > > ; jianbo.liu at linaro.org;
> > > > jerin.jacob at caviumnetworks.com; Keith Wiles > > > intel.com>;
> > Stephen
> > > > Hemminger
> > > > Subject: [dpdk-dev] [PATCH v1 02/28] eal: extract function
> > > > eal_parse_sysfs_valuef
> > > >
> > > > The eal_parse_sysfs_value function accepts a filename however, such
> > interface
> > > > introduces race-conditions to the code. Introduce the variant of this
> > > > function
> > > > that accepts an already opened file instead of a filename.
> > > >
> > > > Signed-off-by: Jan Viktorin
> > > > ---
> > > > lib/librte_eal/common/eal_filesystem.h | 5 +
> > > > lib/librte_eal/linuxapp/eal/eal.c | 36
> > > > +++-
> >
> > > > --
> > > > 2 files changed, 30 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/lib/librte_eal/common/eal_filesystem.h
> > > > b/lib/librte_eal/common/eal_filesystem.h
> > > > index fdb4a70..7875454 100644
> > > > --- a/lib/librte_eal/common/eal_filesystem.h
> > > > +++ b/lib/librte_eal/common/eal_filesystem.h
> > > > @@ -43,6 +43,7 @@
> > > > /** Path of rte config file. */
> > > > #define RUNTIME_CONFIG_FMT "%s/.%s_config"
> > > >
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -115,4 +116,8 @@ eal_get_hugefile_temp_path(char *buffer, size_t
> > buflen,
> > > > const char *hugedir, int
> > > > * Used to read information from files on /sys */
> > > > int eal_parse_sysfs_value(const char *filename, unsigned long *val);
> > > >
> > > > +/** Function to read a single numeric value from a file on the
> > filesystem.
> > > > + * Used to read information from files on /sys */
> > > > +int eal_parse_sysfs_valuef(FILE *f, unsigned long *val);
> > > > +
> > > > #endif /* EAL_FILESYSTEM_H */
> > > > diff --git a/lib/librte_eal/linuxapp/eal/eal.c
> > > > b/lib/librte_eal/linuxapp/eal/eal.c
> > > > index 4b28197..e8fce6b 100644
> > > > --- a/lib/librte_eal/linuxapp/eal/eal.c
> > > > +++ b/lib/librte_eal/linuxapp/eal/eal.c
> > > > @@ -126,13 +126,30 @@ rte_eal_get_configuration(void)
> > > > return _config;
> > > > }
> > > >
> > > > +int
> > > > +eal_parse_sysfs_valuef(FILE *f, unsigned long *val)
> >
> > Hi Shreyansh,
> >
> > >
> > > Trivial Comment: Maybe it is just me, but this function name is too close
> > >
> > to its caller 'eal_parse_sysfs_value'. Probably, the name of the caller can
> > be changed to 'eal_parse_sysfs' because anyways value parsing is being done
> > in this ('eal_parse_sysfs_valuef()) function now. And, of course, dropping
> > the '..f' in this name.
> >
> > I don't like the idea of renaming the orignal function
> > eal_parse_sysfs_value.
> > The function
> > name is not related to its actual body but to its semantics. And the
> > semantics are still
> > the same. This would introduce many other unneeded changes...
> >
>
> Agree. I overlooked that.
>
> > >
> > > I almost skipped the '..f' in the name
[dpdk-dev] [PATCH] app/test: remove rte_pci_dev_ids.h from pci_autotest
On Tue, 14 Jun 2016 16:08:42 +0200 Thomas Monjalon wrote: > 2016-06-14 15:46, Jan Viktorin: > > There are 2 new fake devices for testing PCI infra. All the fake devices s/All the fake/All 3 fake/ > > are now identified by non-existing vendor and device IDs so there is no > > real driver to bind to them. The testing drivers match those IDs. > > Why not removing the existing sysfs entries faking real devices? There is no reason to remove anything. All 3 devices are fakes. The original one was changed to have fake IDs. Is it more clear now? Jan > Thanks
[dpdk-dev] [PATCH v1 07/28] eal/soc: add rte_eal_soc_register/unregister logic
On Wed, 15 Jun 2016 05:57:33 +
Shreyansh Jain wrote:
> Hi Jan,
>
> One more comment which I missed in previous reply:
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Shreyansh Jain
> > Sent: Monday, June 13, 2016 7:50 PM
> > To: Jan Viktorin
> > Cc: David Marchand ; Thomas Monjalon
> > ; Bruce Richardson > intel.com>;
> > Declan Doherty ; jianbo.liu at linaro.org;
> > jerin.jacob at caviumnetworks.com; Keith Wiles ;
> > Stephen
> > Hemminger ; dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v1 07/28] eal/soc: add
> > rte_eal_soc_register/unregister logic
> >
[...]
> > > +
> > > +/**
> > > + * Empty PMD driver based on the SoC infra.
> > > + *
> > > + * The rte_soc_device is usually wrapped in some higher-level struct
> > > + * (eth_driver). We simulate such a wrapper with an anonymous struct
> > > here.
> > > + */
> > > +struct test_wrapper {
> > > + struct rte_soc_driver soc_drv;
> > > +};
> > > +
> > > +struct test_wrapper empty_pmd0 = {
> > > + .soc_drv = {
> > > + .name = "empty_pmd0",
> > > + },
> > > +};
> > > +
> > > +struct test_wrapper empty_pmd1 = {
> > > + .soc_drv = {
> > > + .name = "empty_pmd1",
> > > + },
> > > +};
> > > +
> > > +static int
> > > +count_registered_socdrvs(void)
> > > +{
> > > + int i;
> > > + struct rte_soc_driver *drv;
> > > +
> > > + i = 0;
> > > + TAILQ_FOREACH(drv, _driver_list, next)
> > > + i += 1;
> > > +
> > > + return i;
> > > +}
> > > +
> > > +static int
> > > +test_register_unregister(void)
> > > +{
> > > + struct rte_soc_driver *drv;
> > > + int count;
> > > +
> > > + rte_eal_soc_register(_pmd0.soc_drv);
[...]
> > > +
> > > +extern struct soc_driver_list soc_driver_list; /**< Global list of SoC
> > > drivers. */
> > >
> > > struct rte_soc_id {
> > > const char *compatible; /**< OF compatible specification */
> > > @@ -131,4 +137,21 @@ rte_eal_compare_soc_addr(const struct rte_soc_addr
> > *a0,
> > > return strcmp(a0->name, a1->name);
> > > }
> > >
> > > +/**
> > > + * Register a SoC driver.
> > > + */
> > > +void rte_eal_soc_register(struct rte_soc_driver *driver);
> > > +
> > > +#define RTE_EAL_SOC_REGISTER(name) \
> > > +RTE_INIT(socinitfn_ ##name); \
> > > +static void socinitfn_ ##name(void) \
> > > +{ \
> > > + rte_eal_soc_register(_drv); \
>
> It should be 'rte_eal_soc_register()'.
> As a user of 'RTE_EAL_SOC_REGISTER', I would pass reference to
> 'rte_soc_driver' object. It doesn't have any 'soc_drv' member.
But eth_driver would have it. And other upper-level structs would have it as
well.
>
> I am guessing that because you have created a wrapper structure
> 'test_wrapper' in test_soc.c which contains a 'soc_drv', the macro reflects
> that usage.
I don't assume to use rte_soc_driver directly (similarly to rte_pci_driver).
However, I agree that
it is strange, we should have RTE_ETHDRV_SOC_REGISTER for such purpose (if
needed).
I wanted to avoid redundant arguments to the RTE_EAL_SOC_REGISTER because the
name is
used to create the constructor function. But, it seems that other parts of DPDK
does not
care of this so I will probably give up and make it:
RTE_EAL_SOC_REGISTER(my_cool_drv, _cool_drv.soc_drv);
Thanks for your opinion. I'll fix it in v2.
Jan
>
[...]
>
> -
> Shreyansh
>
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH] app/test: remove rte_pci_dev_ids.h from pci_autotest
There are 2 new fake devices for testing PCI infra. All the fake devices
are now identified by non-existing vendor and device IDs so there is no
real driver to bind to them. The testing drivers match those IDs.
Signed-off-by: Jan Viktorin
Suggested-by: Thomas Monjalon
---
app/test/test_pci.c | 17 +
.../test_pci_sysfs/bus/pci/devices/:01:00.0/device | 2 +-
.../bus/pci/devices/:01:00.0/subsystem_vendor | 2 +-
.../test_pci_sysfs/bus/pci/devices/:01:00.0/vendor | 2 +-
.../test_pci_sysfs/bus/pci/devices/:01:02.0/device | 1 +
.../bus/pci/devices/:01:02.0/resource | 13 +
.../bus/pci/devices/:01:02.0/subsystem_device | 1 +
.../bus/pci/devices/:01:02.0/subsystem_vendor | 1 +
.../test_pci_sysfs/bus/pci/devices/:01:02.0/vendor | 1 +
.../test_pci_sysfs/bus/pci/devices/:02:ab.0/device | 1 +
.../bus/pci/devices/:02:ab.0/resource | 13 +
.../bus/pci/devices/:02:ab.0/subsystem_device | 1 +
.../bus/pci/devices/:02:ab.0/subsystem_vendor | 1 +
.../test_pci_sysfs/bus/pci/devices/:02:ab.0/vendor | 1 +
14 files changed, 42 insertions(+), 15 deletions(-)
create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/device
create mode 100644
app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/resource
create mode 100644
app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/subsystem_device
create mode 100644
app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/subsystem_vendor
create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/vendor
create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:02:ab.0/device
create mode 100644
app/test/test_pci_sysfs/bus/pci/devices/:02:ab.0/resource
create mode 100644
app/test/test_pci_sysfs/bus/pci/devices/:02:ab.0/subsystem_device
create mode 100644
app/test/test_pci_sysfs/bus/pci/devices/:02:ab.0/subsystem_vendor
create mode 100644 app/test/test_pci_sysfs/bus/pci/devices/:02:ab.0/vendor
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 8051e53..354a0ad 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -67,21 +67,14 @@ static int my_driver_init(struct rte_pci_driver *dr,
/* IXGBE NICS */
struct rte_pci_id my_driver_id[] = {
-
-#define RTE_PCI_DEV_ID_DECL_IXGBE(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include
-
-{ .vendor_id = 0, /* sentinel */ },
+ {RTE_PCI_DEVICE(0x0001, 0x1234)},
+ { .vendor_id = 0, /* sentinel */ },
};
struct rte_pci_id my_driver_id2[] = {
-
-/* IGB & EM NICS */
-#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#include
-
-{ .vendor_id = 0, /* sentinel */ },
+ {RTE_PCI_DEVICE(0x0001, 0x)},
+ {RTE_PCI_DEVICE(0x0002, 0xabcd)},
+ { .vendor_id = 0, /* sentinel */ },
};
struct rte_pci_driver my_driver = {
diff --git a/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/device
b/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/device
index 9e4789e..48a6290 100644
--- a/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/device
+++ b/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/device
@@ -1 +1 @@
-0x10fb
+0x1234
diff --git
a/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/subsystem_vendor
b/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/subsystem_vendor
index ce6dc4d..446afb4 100644
--- a/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/subsystem_vendor
+++ b/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/subsystem_vendor
@@ -1 +1 @@
-0x8086
+0x0001
diff --git a/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/vendor
b/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/vendor
index ce6dc4d..446afb4 100644
--- a/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/vendor
+++ b/app/test/test_pci_sysfs/bus/pci/devices/:01:00.0/vendor
@@ -1 +1 @@
-0x8086
+0x0001
diff --git a/app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/device
b/app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/device
new file mode 100644
index 000..f61bbe6
--- /dev/null
+++ b/app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/device
@@ -0,0 +1 @@
+0xabcd
diff --git a/app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/resource
b/app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/resource
new file mode 100644
index 000..f388929
--- /dev/null
+++ b/app/test/test_pci_sysfs/bus/pci/devices/:01:02.0/resource
@@ -0,0 +1,13 @@
+0xd008 0xd00f 0x0014220c
+0x 0x 0x
+0xe020 0xe03f 0x00040101
+0x 0x 0x
+0xd0104000 0xd0107fff 0x0014220c
+0x 0x 0x
+0x
[dpdk-dev] [PATCH v2] config: make libarchive optional
On Tue, 14 Jun 2016 12:01:56 +0200 Thomas Monjalon wrote: > The commit 66819e6 has introduced a dependency on libarchive to be able > to use some tar resources in the unit tests. > It is now an optional dependency because some systems do not have it > installed. > > If CONFIG_RTE_APP_TEST_RESOURCE_TAR is disabled, the PCI test will not > be run. When a "configure" script will be integrated, the libarchive > availability could be checked to automatically enable the option. > > Signed-off-by: Thomas Monjalon > --- > v2: define empty macro linked_tar_resource if disabled > --- Reviewed-by: Jan Viktorin Acked-by: Jan Viktorin
[dpdk-dev] [PATCH] config: make libarchive optional
Hello Thomas,
On Tue, 14 Jun 2016 10:59:49 +0200
Thomas Monjalon wrote:
> The commit 66819e6 has introduced a dependency on libarchive to be able
> to use some tar resources in the unit tests.
> It is now an optional dependency because some systems do not have it
> installed.
I am surprised how big deal is this. So, let's live with this fact.
Thank you, Thomas, for proposing a solution.
>
> If CONFIG_RTE_APP_TEST_RESOURCE_TAR is disabled, the PCI test will not
> be run. When a "configure" script will be integrated, the libarchive
> availability could be checked to automatically enable the option.
>
> Signed-off-by: Thomas Monjalon
> ---
> app/test/Makefile | 11 +++
> app/test/resource.c | 8 ++--
> app/test/test_mp_secondary.c | 4
> app/test/test_resource.c | 5 +
> config/common_base| 1 +
> doc/guides/linux_gsg/sys_reqs.rst | 3 +++
> scripts/test-build.sh | 4
> 7 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/app/test/Makefile b/app/test/Makefile
> index 7e4d484..5ca5c0b 100644
> --- a/app/test/Makefile
> +++ b/app/test/Makefile
> @@ -71,9 +71,6 @@ SRCS-y += test.c
> SRCS-y += resource.c
> SRCS-y += test_resource.c
> $(eval $(call linked_resource,test_resource_c,resource.c))
> -$(eval $(call linked_tar_resource,test_resource_tar,test_resource.c))
> -SRCS-y += test_pci.c
> -$(eval $(call linked_tar_resource,test_pci_sysfs,test_pci_sysfs))
> SRCS-y += test_prefetch.c
> SRCS-y += test_byteorder.c
> SRCS-y += test_per_lcore.c
> @@ -88,6 +85,13 @@ SRCS-y += test_ring.c
> SRCS-y += test_ring_perf.c
> SRCS-y += test_pmd_perf.c
>
> +ifeq ($(CONFIG_RTE_APP_TEST_RESOURCE_TAR),y)
> +$(eval $(call linked_tar_resource,test_resource_tar,test_resource.c))
> +SRCS-y += test_pci.c
> +$(eval $(call linked_tar_resource,test_pci_sysfs,test_pci_sysfs))
> +LDLIBS += -larchive
> +endif
> +
I don't like this very much. I think, the linked_tar_resource can be
disabled at the place of its definition. What about:
ifeq ($(CONFIG_RTE_APP_TEST_RESOURCE_TAR),y)
define linked_tar_resource
...
endef
else
linked_tar_resource =
endif
...
SRCS-$(CONFIG_RTE_APP_TEST_RESOURCE_TAR) += test_pci.c
...
ifeq ($(CONFIG_RTE_APP_TEST_RESOURCE_TAR),y)
LDLIBS += -larchive
endif
> ifeq ($(CONFIG_RTE_LIBRTE_TABLE),y)
> SRCS-y += test_table.c
> SRCS-$(CONFIG_RTE_LIBRTE_PIPELINE) += test_table_pipeline.c
> @@ -194,7 +198,6 @@ CFLAGS += $(WERROR_FLAGS)
> CFLAGS += -D_GNU_SOURCE
>
> LDLIBS += -lm
> -LDLIBS += -larchive
>
> # Disable VTA for memcpy test
> ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
> diff --git a/app/test/resource.c b/app/test/resource.c
> index 8c42eea..0e2b62c 100644
> --- a/app/test/resource.c
> +++ b/app/test/resource.c
> @@ -33,8 +33,6 @@
>
> #include
> #include
> -#include
> -#include
> #include
> #include
>
> @@ -97,6 +95,10 @@ int resource_fwrite_file(const struct resource *r, const
> char *fname)
> return ret;
> }
>
> +#ifdef RTE_APP_TEST_RESOURCE_TAR
> +#include
> +#include
> +
> static int do_copy(struct archive *r, struct archive *w)
> {
> const void *buf;
> @@ -295,6 +297,8 @@ fail:
> return -1;
> }
>
> +#endif /* RTE_APP_TEST_RESOURCE_TAR */
> +
This looks OK.
> void resource_register(struct resource *r)
> {
> TAILQ_INSERT_TAIL(_list, r, next);
> diff --git a/app/test/test_mp_secondary.c b/app/test/test_mp_secondary.c
> index 4dfe418..f66b68f 100644
> --- a/app/test/test_mp_secondary.c
> +++ b/app/test/test_mp_secondary.c
> @@ -245,6 +245,7 @@ run_object_creation_tests(void)
> printf("# Checked rte_lpm_create() OK\n");
> #endif
>
> +#ifdef RTE_APP_TEST_RESOURCE_TAR
> /* Run a test_pci call */
> if (test_pci() != 0) {
> printf("PCI scan failed in secondary\n");
> @@ -252,6 +253,7 @@ run_object_creation_tests(void)
> return -1;
> } else
> printf("PCI scan succeeded in secondary\n");
> +#endif
Is it right to call a test from another test? I think this is
wrong... A user should first test the PCI and then the mp_seconday...
Or?
>
> return 0;
> }
> @@ -266,9 +268,11 @@ test_mp_secondary(void)
> {
> if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> if (!test_pci_run) {
> +#ifdef RTE_APP_TEST_RESOURCE_TAR
> printf("=== Running pre-requisite test of test_pci\n");
> test_pci();
> printf("=== Requisite test done\n");
> +#endif
Similar here.
> }
> return run_secondary_instances();
> }
> diff --git a/app/test/test_resource.c b/app/test/test_resource.c
> index 1e85040..39a6468 100644
> --- a/app/test/test_resource.c
> +++ b/app/test/test_resource.c
> @@ -85,6 +85,7 @@ static int test_resource_c(void)
> return 0;
> }
>
> +#ifdef RTE_APP_TEST_RESOURCE_TAR
> REGISTER_LINKED_RESOURCE(test_resource_tar);
>
> static
[dpdk-dev] [PATCH v5 10/10] app/test: do not dump PCI devices in blacklist test
Dumping of devices in a unittest is useless. Instead, test whether
the test has been set up well - i.e. there are no devices.
Signed-off-by: Jan Viktorin
---
app/test/test_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 362ae3e..8051e53 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -238,7 +238,8 @@ test_pci_blacklist(void)
struct rte_devargs_list save_devargs_list;
printf("Dump all devices\n");
- rte_eal_pci_dump(stdout);
+ TEST_ASSERT(TAILQ_EMPTY(_driver_list),
+ "pci_driver_list not empty");
rte_eal_pci_register(_driver);
rte_eal_pci_register(_driver2);
--
2.8.0
