[dpdk-dev] [PATCH v6] VFIO: Avoid to enable vfio while the module not loaded

2015-01-15 Thread Burakov, Anatoly
Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, January 15, 2015 1:38 PM > To: Qiu, Michael > Cc: Burakov, Anatoly; dev at dpdk.org; Xie, Huawei > Subject: Re: [PATCH v6] VFIO: Avoid to enable vfio while the module not > loaded > > > > When vfio

[dpdk-dev] [PATCH v2 1/2] vfio: fix build if build envrionment is on old kernel

2015-07-10 Thread Burakov, Anatoly
Hi Stephen, > --- /dev/null > +++ b/lib/librte_eal/linuxapp/eal/compat_vfio.h > @@ -0,0 +1,181 @@ Wouldn't this need a GPL license header? Thanks,Anatoly

[dpdk-dev] libhugetlbfs

2015-07-23 Thread Burakov, Anatoly
Hi Sergio >Then there is the issue with multi-process; because they return a file > descriptor while >unlinking the file, we would need some sort of Inter-Process That's kind of what VFIO does for multiprocess, so you may want to look at that in case you decide to get down that route :)

[dpdk-dev] Headers files with BSD license in kernel

2015-06-10 Thread Burakov, Anatoly
> 2015-06-10 01:20, Zhang, Helin: > > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > > > > On Tue, Jun 09, 2015 at 12:40:57PM -0500, Miguel Bernal Marin wrote: > > > > > > Hi, > > > > > > > > > > > > I'm working on Clear Linux project, and when I was integrating > > > > > >

[dpdk-dev] [PATCH] vfio: eventfd should be non-block and not inherited

2015-04-29 Thread Burakov, Anatoly
> Set internal event file descriptor to be non-block and not inherited across > exec. This prevents accidental hangs and passing in anothr thread. > > Signed-off-by: Stephen Hemminger > --- > lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

[dpdk-dev] [PATCH 1/3] vfio: Added hot removal feature for vfio

2015-08-04 Thread Burakov, Anatoly
Hi Harpal, > This patch will add a new API i.e. pci_vfio_unmap_resource. > It will basically cleanup all the vfio resources allocated for a device. > cleanup includes :- > 1) removing vfio_res from vfio_res_list > 2) unmap mapped bars > 3) close device fd > 4) close group fd > 5) free vfio_res

[dpdk-dev] [PATCH 1/3] vfio: Added hot removal feature for vfio

2015-08-07 Thread Burakov, Anatoly
Hi Harpal, > I think maintaining a ref count of groups will solve this problem. Yes, refcounting seems like the best way to solve this problem. > Additionally, I have found a bug in existing design in case of multiple > devices of same group. > <...> > Therefore, I will provide a fix?for

[dpdk-dev] ivshmem mmap to specific address

2015-12-09 Thread Burakov, Anatoly
Hi Eli > Is there a method to guarantee that this mapping won't fail, even for > different processes, that might have large code or constructors running even > before main? I'm afraid there is none. That's the nature of the beast. The best you can do is map stuff into a different address range

[dpdk-dev] [PATCH] vfio: support iommu group zero

2015-12-10 Thread Burakov, Anatoly
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen > Hemminger > Sent: Wednesday, December 9, 2015 5:56 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] vfio: support iommu group zero > > The current implementation of VFIO will not with the new

[dpdk-dev] VFIO no-iommu

2015-12-16 Thread Burakov, Anatoly
Hi Alex, > On Wed, 2015-12-16 at 04:04 +, Ferruh Yigit wrote: > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote: > > I tested the DPDK (HEAD of master) with the patch, with help of > > Anatoly, and DPDK works in no-iommu environment with a little > > modification. > > > >

[dpdk-dev] VFIO no-iommu

2015-12-16 Thread Burakov, Anatoly
Hi Thomas, > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote: > > So it works. ?Is it acceptable? ?Useful? ?Sufficiently complete? ?Does > > it imply deprecating the uio interface? ?I believe the feature that > > started this discussion was support for MSI/X interrupts so that

[dpdk-dev] VFIO no-iommu

2015-12-16 Thread Burakov, Anatoly
Hi Alex, > On Wed, 2015-12-16 at 08:35 +0000, Burakov, Anatoly wrote: > > Hi Alex, > > > > > On Wed, 2015-12-16 at 04:04 +, Ferruh Yigit wrote: > > > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote: > > > > I tested the

[dpdk-dev] VFIO no-iommu

2015-12-17 Thread Burakov, Anatoly
Hi Thomas, > > Hi Thomas, > > > > > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote: > > > > So it works. Is it acceptable? Useful? Sufficiently complete? > > > > Does it imply deprecating the uio interface? I believe the > > > > feature that started this discussion was

[dpdk-dev] [PATCH] vfio: add no-iommu support

2015-12-21 Thread Burakov, Anatoly
Hi Ferruh, > This is based on patch from Alex Williamson: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=03 > 3291eccbdb > plus > http://dpdk.org/dev/patchwork/patch/9598/ > > This patch is intended to test above patches on DPDK rather than official > patch to DPDK.

[dpdk-dev] [PATCH] vfio: add no-iommu support

2015-12-21 Thread Burakov, Anatoly
Hi Ferruh, > On Mon, Dec 21, 2015 at 03:15:46PM +0000, Burakov, Anatoly wrote: > > > This is based on patch from Alex Williamson: > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm > > > it/?id=03 > > > 3291eccbdb > > > plu

[dpdk-dev] VFIO no-iommu

2015-12-23 Thread Burakov, Anatoly
Hi Alex, > I've re-posted the unified patch upstream and it should start showing up in > the next linux-next build. ?I expect the dpdk code won't be merged until > after this gets back into a proper kernel, but could we get the dpdk > modifications posted as rfc for others looking to try it? I

[dpdk-dev] [PATCH] eal: map io resources for non x86 architectures

2015-12-29 Thread Burakov, Anatoly
Hi Santosh, > On Fri, Dec 18, 2015 at 6:25 PM, Santosh Shukla > wrote: > > On Fri, Dec 18, 2015 at 1:51 PM, Yuanhan Liu > > wrote: > >> On Fri, Dec 18, 2015 at 01:24:41PM +0530, Santosh Shukla wrote: > >>> >> I guess we have done enough evaluation / investigation that > >>> >> suggest - so to

[dpdk-dev] [PATCH] eal: map io resources for non x86 architectures

2015-12-29 Thread Burakov, Anatoly
Hi Santosh, > Look at kernel/resource.c, it exports two symbol ioport_resource and > iomem_resource and sets appropriate flag type i.e.. IORESOURCE_IO and > IORESOURCE_MEM. In virtio-net case; it creates both pci region i.e.. > _io bar and _mem bar. dpdk virtio pmd driver (<= 0.95 virtio spec)

[dpdk-dev] VFIO in setup.sh

2015-03-31 Thread Burakov, Anatoly
> > 3. Why depend on location of vfio module in kernel tree? > >modprobe does the right thing and finds it. > > > > VFIO_PATH="kernel/drivers/vfio/pci/vfio-pci.ko" > > > > echo "Loading VFIO module" > > /sbin/lsmod | grep -s vfio_pci > /dev/null > > if [ $? -ne 0 ] ; then > >

[dpdk-dev] VFIO in setup.sh

2015-03-31 Thread Burakov, Anatoly
> I think the whole process of VFIO binding maybe needs at least a second > thought regarding corner cases and security. > > 1) in the setup process, there currently is no mechanism that checks if the > Device to be used has other devices in the > same iommu group that need to be bound to VFIO

[dpdk-dev] VFIO in setup.sh

2015-03-31 Thread Burakov, Anatoly
> iommu groups already exist before vfio-pci is loaded. > The whole setup process as described in the VFIO documentation, where a > PCIe device shares an iommu group with other devices, can therefore be > automated. Some time ago I wrote a ruby script that does exactly that >

[dpdk-dev] IGB_UIO port unbinding

2014-04-10 Thread Burakov, Anatoly
Hi everyone As you may or may not know, the CONFIG_RTE_EAL_UNBIND_PORTS was deprecated in the official Intel(r) DPDK 1.6.0 release package. However, the code itself (e.g. in lib/librte_eal/linuxapp/eal_pci.c and other places) to support that config option was not removed. My question would be,

[dpdk-dev] IGB_UIO port unbinding

2014-04-11 Thread Burakov, Anatoly
Hi Prashant, > There was a usecase with ESXi VMXNET3 NIC where I had to use this > parameter set to Y to make it work. > So kindly ensure that the initialization of vmxnet3 NIC is not vulnerable. > Did you try it on the latest 1.6.x code (that option was removed)? More to the point, I can't

[dpdk-dev] IGB_UIO port unbinding

2014-04-11 Thread Burakov, Anatoly
Hi Prashant, > I might have used the term 'initialization' in a wrong fashion. > But I have confirmed, the issue was related to this commit (which Thomas > brought to my notice) -- > > http://dpdk.org/browse/dpdk/commit/?id=18f02ff75949de9c2468 > > The above should get you the context for the

[dpdk-dev] [PATCH] Remove RTE_EAL_UNBIND_PORTS-related code

2014-04-11 Thread Burakov, Anatoly
RTE_EAL_UNBIND_PORTS was deprecated in DPDK 1.4.0 and removed in 1.6.0, but the code was not removed. Signed-off-by: Anatoly Burakov --- lib/librte_eal/linuxapp/eal/eal_pci.c | 221 -- 1 file changed, 221 deletions(-) diff --git

[dpdk-dev] IGB_UIO port unbinding

2014-04-14 Thread Burakov, Anatoly
Hi Stephen, > I actually liked the unbind code that was there. It meant that additional > logic > did not have to be added to the startup script to do PCI discovery and > finding/mapping devices. > > As it is the EAL startup process is a bit of a mess. It assumes that various > bits > of

[dpdk-dev] [PATCH 0/3] remove RTE_EAL_UNBIND_PORTS related code

2014-04-14 Thread Burakov, Anatoly
Hi David, > For now, I have a problem with your patch as it breaks drivers that use > RTE_PCI_DRV_FORCE_UNBIND flag, since it removes the part where this flag > is handled. Besides, I can see some remaining parts mentioning > pci_switch_module() in comments. I wonder if this functionality is

[dpdk-dev] [PATCH 0/3] remove RTE_EAL_UNBIND_PORTS related code

2014-04-14 Thread Burakov, Anatoly
Hi David, > This functionality is at least used by virtio-net-pmd. > So we cannot remove this without a fix for virtio-net-pmd. It appears that virtio-net-pmd hasn't been merged in yet? At least I can't see it in the git tree for 1.6 release. > Yet, even if we remove this from the eal, I think

[dpdk-dev] IGB_UIO port unbinding

2014-04-14 Thread Burakov, Anatoly
Hi Stephen, > The problem is that doing the initialization requires duplicating all the > logic to > probe the PCI bus and do blacklisting etc in the startup application. Not quite sure what you're referring to here, could you please elaborate a bit more? If you mean the EAL PCI probing and

[dpdk-dev] [PATCH 1/3] pci: pci_switch_module cleanup

2014-04-15 Thread Burakov, Anatoly
> The pci_switch_module() function should only do what its name tells: unbind > pci devices and rebind them on the specified kernel driver. > Hence, it can not call pci_uio_map_resource(). > > Call to pci_uio_map_resource() should be moved to > rte_eal_pci_probe_one_driver() so that we can

[dpdk-dev] [PATCH 2/3] pci: move RTE_PCI_DRV_FORCE_UNBIND handling out of #ifdef

2014-04-15 Thread Burakov, Anatoly
> Move RTE_PCI_DRV_FORCE_UNBIND flag handling out of > RTE_EAL_UNBIND_PORTS section. > This had nothing to do with RTE_EAL_UNBIND_PORTS anyway. > > Signed-off-by: David Marchand Acked-by: Anatoly Burakov Best regards, Anatoly Burakov DPDK SW Engineer

[dpdk-dev] [PATCH 3/3] pci: remove deprecated RTE_EAL_UNBIND_PORTS option

2014-04-15 Thread Burakov, Anatoly
> RTE_EAL_UNBIND_PORTS was deprecated in DPDK 1.4.0 and removed in > 1.6.0, but the code was not removed. > > The bind/unbind operations should not be handled by the eal. > These operations should be either done outside of dpdk or inside the PMDs > themselves as these are their problems. > >

[dpdk-dev] [PATCH] EAL: Take reserved hugepages into account

2014-04-16 Thread Burakov, Anatoly
Some applications reserve hugepages for later use, but DPDK doesn't take reserved pages into account when calculating number of available number of hugepages. This patch adds reading from "resv_hugepages" file in addition to "free_hugepages". --- lib/librte_eal/linuxapp/eal/eal_hugepage_info.c

[dpdk-dev] [PATCH 0/7] pci cleanup

2014-04-29 Thread Burakov, Anatoly
> Here is an attempt at having an equal implementation in bsd and linux > eal_pci.c. > It results in following changes : > - checks on driver flag in bsd which were missing > - remove virtio-uio workaround in linux eal_pci.c > - remove deprecated RTE_EAL_UNBIND_PORTS option > > Along the way, I

[dpdk-dev] [RFC] PCI config access for drivers

2014-08-27 Thread Burakov, Anatoly
Hi Stephen, > Some drivers need ability to access PCI config (for example for power > management). This > adds an abstraction to do this; only implemented on Linux, but should be > possible on BSD. Since VFIO has to go to PCI config space too for some things, could you please amend your patch

[dpdk-dev] [PATCH] VFIO: Avoid to enable vfio while the module not loaded

2014-12-04 Thread Burakov, Anatoly
Hi Michael > When vfio module is not loaded when kernel support vfio feature, the > routine still try to open the container to get file description. > > This action is not safe, and of cause got error messages: > > EAL: Detected 40 lcore(s) > EAL: unsupported IOMMU type! > EAL: VFIO support

[dpdk-dev] [PATCH] VFIO: Avoid to enable vfio while the module not loaded

2014-12-04 Thread Burakov, Anatoly
Hi Michael > When vfio module is not loaded when kernel support vfio feature, the > routine still try to open the container to get file description. > > This action is not safe, and of cause got error messages: > > EAL: Detected 40 lcore(s) > EAL: unsupported IOMMU type! > EAL: VFIO support

[dpdk-dev] [PATCH] VFIO: Avoid to enable vfio while the module not loaded

2014-12-04 Thread Burakov, Anatoly
Hi Michael > But indeed, when try to unload both vfio and vfio_iommu_type1, > /dev/vfio/vfio still there, I'm also surprise. > > My ENV is fedora20, kernel version 3.6.7-200 X86_64. > > Believe or not, you can have a try, it seems a kernel issue. > > When you unload both two modules, then open

[dpdk-dev] [PATCH v3] VFIO: Avoid to enable vfio while the module not loaded

2014-12-08 Thread Burakov, Anatoly
> When vfio module is not loaded when kernel support vfio feature, the > routine still try to open the container to get file description. > > This action is not safe, and of cause got error messages: > > EAL: Detected 40 lcore(s) > EAL: unsupported IOMMU type! > EAL: VFIO support could not be

[dpdk-dev] [PATCH v4] VFIO: Avoid to enable vfio while the module not loaded

2014-12-08 Thread Burakov, Anatoly
> When vfio module is not loaded when kernel support vfio feature, the > routine still try to open the container to get file description. > > This action is not safe, and of cause got error messages: > > EAL: Detected 40 lcore(s) > EAL: unsupported IOMMU type! > EAL: VFIO support could not be

[dpdk-dev] [PATCH v2] VFIO: Avoid to enable vfio while the module not loaded

2014-12-08 Thread Burakov, Anatoly
Hi Michael > I don't think so, if we check module "vfio", but if given module name is > "vfio_xx", it will also correct if use strncmp. Sorry I missed this the last time. I don't think that is the case. If you do strncmp on sizeof(buffer), strncmp will always check 30 bytes. That way if you

[dpdk-dev] [PATCH v2] VFIO: Avoid to enable vfio while the module not loaded

2014-12-09 Thread Burakov, Anatoly
Hi Michael, > > Yes, you are right, strncmp() will check 30 bytes if use sizeof(buffer). > > But any issue of strcmp() ? This rountin cares about exactly match. I think no > need to convert to strncmp() if it does have other issue. > > > fscanf with fgets would be better too, to make sure we

[dpdk-dev] [PATCH v5] VFIO: Avoid to enable vfio while the module not loaded

2014-12-10 Thread Burakov, Anatoly
> > When vfio module is not loaded when kernel support vfio feature, the > routine still try to open the container to get file description. > > This action is not safe, and of cause got error messages: > > EAL: Detected 40 lcore(s) > EAL: unsupported IOMMU type! > EAL: VFIO support could not

[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT

2014-12-16 Thread Burakov, Anatoly
> On 16/12/14 4:54 am, "Thomas Monjalon" > wrote: > > >2014-12-12 13:48, Sujith Sankar: > >> This patch corrects the usage of the flag VFIO_PRESENT in enic driver. > > > >Please, could you explain why the flag VFIO_PRESENT was not well used? > > Without including eal_vfio.h, VFIO_PRESENT is not

[dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT

2014-12-16 Thread Burakov, Anatoly
> -Original Message- > From: Sujith Sankar (ssujith) [mailto:ssujith at cisco.com] > Sent: Tuesday, December 16, 2014 10:34 AM > To: Burakov, Anatoly; Thomas Monjalon > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] enic: corrected the usage of VFIO_PRESENT >

[dpdk-dev] How to debug packet sends to virtual functions

2014-02-04 Thread Burakov, Anatoly
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mats Liljegren > Sent: Tuesday, February 04, 2014 10:45 AM > To: jigsaw > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] How to debug packet sends to virtual functions > > Hi Qinglai, > > Thanks for the

[dpdk-dev] FW: couple of minor compilation errors in DPDK 1.6 (/lib/librte_eal/linuxapp/eal/eal_ivshmem.c)

2014-02-04 Thread Burakov, Anatoly
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jyotiswarup > Raiturkar > Sent: Tuesday, February 04, 2014 3:33 AM > To: dev at dpdk.org > Cc: Jyotiswarup Raiturkar > Subject: [dpdk-dev] couple of minor compilation errors in DPDK 1.6 >

[dpdk-dev] How to debug packet sends to virtual functions

2014-02-04 Thread Burakov, Anatoly
> -Original Message- > From: Mats Liljegren [mailto:liljegren.mats2 at gmail.com] > Sent: Tuesday, February 04, 2014 11:48 AM > To: Burakov, Anatoly > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] How to debug packet sends to virtual functions > >

[dpdk-dev] How to debug packet sends to virtual functions

2014-02-04 Thread Burakov, Anatoly
> -Original Message- > From: Mats Liljegren [mailto:liljegren.mats2 at gmail.com] > Sent: Tuesday, February 04, 2014 1:04 PM > To: Burakov, Anatoly > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] How to debug packet sends to virtual functions > > Hi Ana

[dpdk-dev] How to debug packet sends to virtual functions

2014-02-13 Thread Burakov, Anatoly
Hi Mats > Hi Anatoly, > > I finally got things working. I apparently missed an "ifconfig up" in > the > guest, before starting dpdk. I'm still confused why this would be needed. Is > dpdk unable to do a full initialization of the virtual function from the > guest? > You wouldn't be able to

[dpdk-dev] How to debug packet sends to virtual functions

2014-02-17 Thread Burakov, Anatoly
Hi Mats > The guest starts with loading the igbvf kernel driver, uses ifconfig up, > then loads and binds to igb_uio. After that, DPDK works. If I skip any step > here it doesn't work. Skipping "ifconfig" step resulted in packets being > received but I couldn't send them, they just got queued up

[dpdk-dev] How to debug packet sends to virtual functions

2014-02-17 Thread Burakov, Anatoly
> I found the bug, it was an illegal arp entry that I had created causing the > problem. So this case has been solved. > > I re-checked this ifconfig issue, and now I can get it to work without > ifconfig > in the guest. Not sure why it didn't work without it previously, but > apparently, there

[dpdk-dev] Ability to/impact of running with smaller page sizes

2014-07-01 Thread Burakov, Anatoly
Hi Matt, > I'm curious - is it possible in practical terms to run DPDK without hugepages? Starting with release 1.7.0, support for VFIO was added, which allows using DPDK without hugepages at al (including RX/TX rings) via the --no-huge command-line parameter. Bear in mind though that you'll

[dpdk-dev] [PATCH v4 05/20] pci: Rename RTE_PCI_DRV_NEED_IGB_UIO to RTE_PCI_DRV_NEED_MAPPING

2014-06-04 Thread Burakov, Anatoly
> Rename the RTE_PCI_DRV_NEED_IGB_UIO to be more generic. > > Signed-off-by: Anatoly Burakov NAK, virtio change got lost in the rebases :-( Best regards, Anatoly Burakov DPDK SW Engineer

[dpdk-dev] [PATCH 00/10] igb_uio patches

2014-06-10 Thread Burakov, Anatoly
> These apply to the current DPDK tree, and are an alternative to the patches > from Alan. It provides indication of IRQ mode via sysfs attribute. They > include > cleanups and fixes to allow use of MSI and do proper fallback for the case > where MSI-X vectors are exhausted. > > Hi Stephen, > >

[dpdk-dev] [PATCH v5 00/20] Add VFIO support to DPDK

2014-06-13 Thread Burakov, Anatoly
> This patchset adds support for using VFIO instead of IGB_UIO to map the > device BARs. > NAK, there's a small problem with FreeBSD, v6 is coming. Best regards, Anatoly Burakov DPDK SW Engineer

[dpdk-dev] mmap() hint address

2014-06-16 Thread Burakov, Anatoly
Hi Bruce, Stephen, > > Hello, > > > > I have seen a case where a secondary DPDK process tries to map uio > > resource in which mmap() normally sends the corresponding virtual > > address as a hint address. However on some instances mmap() returns a > > virtual address that is not the hint

[dpdk-dev] [PATCH v6 00/20] Add VFIO support to DPDK

2014-06-16 Thread Burakov, Anatoly
Hi Thomas, > The signed-off-by line disappeared from v6 patches. > I assume to be > Signed-off-by: Anatoly Burakov Please > confirm. Yes, sorry about that, was having a rather long day :-( Both VFIO and tailq patches assume signoff. Best regards, Anatoly Burakov DPDK SW Engineer

[dpdk-dev] vfio detection

2014-06-17 Thread Burakov, Anatoly
Hi Bruce, > I have a number of NIC ports which were working correctly yesterday and are > bound correctly to the igb_uio driver - and I want to keep using them > through the igb_uio driver for now, not vfio. However, whenever I run a > dpdk application today, I find that the vfio kernel module is

[dpdk-dev] [PATCH] vfio: make container open error non-fatal

2014-06-17 Thread Burakov, Anatoly
Hi Bruce, > The below patch is the quickest fix I found to make my applications work > again, but I'm not sure it's the best solution. Can anyone else offer other > suggestions to improve this? Are you running things as root? If not, I suggest to try and use the setup.sh script to correct

[dpdk-dev] [PATCH] vfio: make container open error non-fatal

2014-06-17 Thread Burakov, Anatoly
Hi Bruce, > Hi Bruce, > > > The below patch is the quickest fix I found to make my applications > > work again, but I'm not sure it's the best solution. Can anyone else > > offer other suggestions to improve this? > > Are you running things as root? If not, I suggest to try and use the setup.sh

[dpdk-dev] [PATCH 0/7] Make DPDK tailqs fully local

2014-06-17 Thread Burakov, Anatoly
Found a few races, a v2 will be submitted shortly. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Anatoly Burakov > Sent: Friday, June 13, 2014 4:29 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 0/7] Make DPDK tailqs fully local Best regards,

[dpdk-dev] [PATCH] vfio: open VFIO container at startup rather than during init

2014-06-18 Thread Burakov, Anatoly
Hi Thomas, > Subject: Re: [dpdk-dev] [PATCH] vfio: open VFIO container at startup rather > than during init > > > Signed-off-by: Anatoly Burakov > > Please Anatoly, could you provide a text explaining what was broken and > why you fixed it this way? What was broken was if, for some reason,

[dpdk-dev] [PATCH 1/9] eal: map shared config into exact same address as primary process

2014-06-18 Thread Burakov, Anatoly
Hi Konstantin, > I think we introduce a race window here. > If secondary process would do first mmap() before rte_config.mem_config- > >mem_cfg_addr was properly set by primary process, then it will try to do > second mmap() with wrong address. > I think we need to do second mmap() straight after

[dpdk-dev] [PATCH] vfio: open VFIO container at startup rather than during init

2014-06-18 Thread Burakov, Anatoly
Hi Cristian, > I would suggest we add a log message explaining which mechanism is loaded > (igb_uio/vfio) and why (e.g. tried vfio first but container could not be > opened, so falling back to igb_uio, etc). This already happens. If the container could not be loaded for whatever reason, the log

[dpdk-dev] vfio detection

2014-06-18 Thread Burakov, Anatoly
Hi Bruce, > > > I have a number of NIC ports which were working correctly yesterday > > > and are bound correctly to the igb_uio driver - and I want to keep > > > using them through the igb_uio driver for now, not vfio. However, > > > whenever I run a dpdk application today, I find that the vfio

[dpdk-dev] [PATCH] vfio: open VFIO container at startup rather than during init

2014-06-18 Thread Burakov, Anatoly
Hi Neil > I think what Thomas wants is for you to resend the patch with a proper > changelog entry added to it, so the commit has an explination of what was > changed and, for posterity. Got it. Can I also incorporate your changes to error codes as well? Best regards, Anatoly Burakov DPDK SW

[dpdk-dev] [PATCH] eal: clear errno before calling strtoull() to parse base_virtaddr

2014-06-19 Thread Burakov, Anatoly
Hi Aaron, It seems that Pablo De Lara has beat you to it by a few minutes :-) Are there any other places this could potentially happen? > Must reset errno to zero before calling strtoull(), else on success it could > be > any arbitrary value from past errors. > > Signed-off-by: Aaron Campbell

[dpdk-dev] [PATCH] eal: Fixed EAL option --base-virtaddr

2014-06-19 Thread Burakov, Anatoly
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Thursday, June 19, 2014 4:35 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] eal: Fixed EAL option --base-virtaddr > > From: Pablo de Lara > > When parsing EAL option

[dpdk-dev] mmap() hint address

2014-06-20 Thread Burakov, Anatoly
as hugepages. Thanks, Anatoly > -Original Message- > From: Gooch, Stephen [mailto:stephen.gooch at windriver.com] > Sent: Friday, June 20, 2014 3:37 PM > To: Burakov, Anatoly; Richardson, Bruce; dev at dpdk.org > Subject: RE: mmap() hint address > > Hello, >

[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK

2014-05-01 Thread Burakov, Anatoly
apply David's patches beforehand. Signed-off by: Anatoly Burakov Anatoly Burakov (16): Separate igb_uio mapping into a separate file Distinguish between legitimate failures and non-fatal errors Rename RTE_PCI_DRV_NEED_IGB_UIO to RTE_PCI_DRV_NEED_MAPPING Make igb_uio compilation optional

[dpdk-dev] [PATCH 02/16] [RFC] [VFIO] Distinguish between legitimate failures and non-fatal errors

2014-05-01 Thread Burakov, Anatoly
Currently, EAL does not distinguish between actual failures and expected initialization errors. E.g. sometimes the driver fails to initialize because it was not supposed to be initialized in the first place, such as device not being managed by said driver. This patch makes EAL fail on actual

[dpdk-dev] [PATCH 03/16] [RFC] [VFIO] Rename RTE_PCI_DRV_NEED_IGB_UIO to RTE_PCI_DRV_NEED_MAPPING

2014-05-01 Thread Burakov, Anatoly
Rename the RTE_PCI_DRV_NEED_IGB_UIO to be more generic, retain old macro for backwards compatibility. Probably should be removed in one of the next releases. Signed-off-by: Anatoly Burakov diff --git a/app/test/test_pci.c b/app/test/test_pci.c index 445cf57..e13f635 100644 ---

[dpdk-dev] [PATCH 01/16] [RFC] [VFIO] Separate igb_uio mapping into a separate file

2014-05-01 Thread Burakov, Anatoly
In order to make the code a bit more clean while using multiple drivers, IGB_UIO mapping has been separated into its own file. Signed-off-by: Anatoly Burakov create mode 100644 lib/librte_eal/linuxapp/eal/eal_pci_uio.c create mode 100644 lib/librte_eal/linuxapp/eal/include/eal_pci_init.h

[dpdk-dev] [PATCH 05/16] [RFC] [VFIO] Moved interrupt type out of igb_uio

2014-05-01 Thread Burakov, Anatoly
Moving interrupt type enum out of igb_uio and renaming it to be more generic. Such a strange header naming and separation is done mostly to make coming virtio patches easier to port to dpdk.org tree. Signed-off-by: Anatoly Burakov create mode 100644

[dpdk-dev] [PATCH 06/16] [RFC] [VFIO] Add support for VFIO in Linuxapp targets

2014-05-01 Thread Burakov, Anatoly
Make VFIO compilation optional for all configs. Signed-off-by: Anatoly Burakov diff --git a/config/defconfig_i686-default-linuxapp-gcc b/config/defconfig_i686-default-linuxapp-gcc index ea90f12..5410f57 100644 --- a/config/defconfig_i686-default-linuxapp-gcc +++

[dpdk-dev] [PATCH 04/16] [RFC] [VFIO] Make igb_uio compilation optional

2014-05-01 Thread Burakov, Anatoly
Currently, igb_uio is always compiled. Since no Linux distribution would want to include igb_uio by default or even with DPDK, we need to make sure that igb_uio compilation can be optional (i.e. some distributions could ship DPDK with VFIO support only). Signed-off-by: Anatoly Burakov diff

[dpdk-dev] [PATCH 10/16] [RFC] [VFIO] Added support for selecting VFIO interrupt type from EAL command-line

2014-05-01 Thread Burakov, Anatoly
Unlike igb_uio, VFIO interrupt type is not set by kernel module parameters but is set up via ioctl() calls at runtime. This warrants a new EAL command-line parameter. It will have no effect if VFIO is not compiled, but will set VFIO interrupt type to either "legacy" or "msix" if VFIO support is

[dpdk-dev] [PATCH 13/16] [RFC] [VFIO] Removed PCI ID table from igb_uio

2014-05-01 Thread Burakov, Anatoly
Note that since igb_uio no longer has a PCI ID list, it can now be bound to any device, not just those explicitly supported by DPDK. In other words, it now behaves similar to PCI stub, VFIO and other generic PCI drivers. Therefore to bind a new device to igb_uio, the user will now have to first

[dpdk-dev] [PATCH 11/16] [RFC] [VFIO] Make --no-huge use mmap instead of malloc

2014-05-01 Thread Burakov, Anatoly
This makes it possible to run DPDK without hugepage memory when VFIO is used, as VFIO uses virtual addresses to set up DMA mappings. Signed-off-by: Anatoly Burakov diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c index 73a6394..b075145 100644 ---

[dpdk-dev] [PATCH 07/16] [RFC] [VFIO] Add support for VFIO interrupts, add VFIO header

2014-05-01 Thread Burakov, Anatoly
Creating code to handle VFIO interrupts in EAL interrupts, and also adding a header eal_vfio.h. This header checks two things: * checks if CONFIG_RTE_EAL_VFIO was enabled during build time * checks that kernel version is 3.6+ so that DPDK would still compile on older kernels despite VFIO

[dpdk-dev] [PATCH 12/16] [RFC] [VFIO] Adding unit tests for VFIO EAL command-line parameter

2014-05-01 Thread Burakov, Anatoly
Adding unit tests for VFIO interrupt type command-line parameter. We don't know if VFIO is compiled (eal_vfio.h header is internal to Linuxapp EAL), we check this flag regardless. Also, quick-fixed a bug in base_virtaddr parsing that prevented it from working (making unit test fail), will later

[dpdk-dev] [PATCH 15/16] [RFC] [VFIO] Added support for VFIO drivers in dpdk_nic_bind.py

2014-05-01 Thread Burakov, Anatoly
Since igb_uio no longer has a PCI ID list, the script will no longer distinguish between supported and unsupported NICs. There's a weird behaviour of sysfs when a new device ID is added to new_id. Subsequent writing to "bind" will result in IOError on closing the file. This error is harmless but

[dpdk-dev] [PATCH 16/16] [RFC] [VFIO] Adding support for VFIO to setup.sh

2014-05-01 Thread Burakov, Anatoly
Support for loading/unloading VFIO drivers, binding/unbinding devices to/from VFIO, also setting up correct userspace permissions. Signed-off-by: Anatoly Burakov diff --git a/tools/setup.sh b/tools/setup.sh index 39be8fc..2ffa55a 100755 --- a/tools/setup.sh +++ b/tools/setup.sh @@ -187,6

[dpdk-dev] [PATCH 1/7] pci: fix potential mem leak

2014-05-01 Thread Burakov, Anatoly
Hi David, > Looking at bsd implementation, we can see that there is a potential mem > leak in linux implementation. Fix this. > > Signed-off-by: David Marchand > --- > lib/librte_eal/linuxapp/eal/eal_pci.c |1 + > 1 file changed, 1 insertion(+) > > diff --git

[dpdk-dev] [PATCH RFC] eal: change core mask input format

2014-05-01 Thread Burakov, Anatoly
> From: Didier Pallard > > In current version, coremask can only be specified using a bitmask. > It will now be possible to specify core masks in 2 different ways: > - Using a bitmask (-c 0xnnn): bitmask must be in hex format and start with 0x > - Using a core set description in following

[dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation

2014-05-01 Thread Burakov, Anatoly
Hi David, Didier, > + /* Set memory amount per socket; round up to be sure that > sum of all */ > + /* sockets allocation is greater than requested memory size > */ > + for (socket_id=0 ; socket_id socket_id++) { > +

[dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation

2014-05-02 Thread Burakov, Anatoly
Hi again David/Didier, > Can I suggest to do an RTE_MAX between (internal_config.memory - > total_mem) and (internal_config.memory * cpu_per_socket[socket_id] + > rte_lcore_count() - 1) / rte_lcore_count() ? I don't think it's a good idea > to go > over the requested amount. Let the last core

[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK

2014-05-02 Thread Burakov, Anatoly
Hi Stephen, > Will this work in guest? or only on bare metal? VFIO is Linux-only, and in theory will be able to work on the guest, but not at the moment, since it requires IOMMU. There was a GSoC proposal for KVM to do IOMMU implementation, and there were a few AMD IOMMU-emulation patches

[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK

2014-05-02 Thread Burakov, Anatoly
Hi Chris, > hmm, vfio requires iommu support, however virtio pmd? That's correct, virtio will not work with VFIO as it stands. However it's not the fault of this patch but rather lack of emulated IOMMU on the guest :-) Best regards, Anatoly Burakov DPDK SW Engineer

[dpdk-dev] [PATCH 16/16] [RFC] [VFIO] Adding support for VFIO to setup.sh

2014-05-02 Thread Burakov, Anatoly
Hi Stephen, > > > > # > > +# Unloads VFIO modules. > > +# > > +remove_vfio_module() > > +{ > > + echo "Unloading any existing VFIO module" > > + /sbin/lsmod | grep -s vfio > /dev/null > > + if [ $? -eq 0 ] ; then > > + sudo /sbin/rmmod vfio-pci > > + sudo /sbin/rmmod

[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK

2014-05-06 Thread Burakov, Anatoly
Hi Vincent, > My 2 cents: >http://dpdk.org/browse/virtio-net-pmd/tree/README.rst > it works without UIO. > I meant the in-tree virtio driver. Obviously anything that doesn't depend on UIO will work with VFIO as well (or even without both - compilation of both will be optional). Best

[dpdk-dev] [PATCH 4/5] memzone: add iterator function

2014-05-06 Thread Burakov, Anatoly
Hi Stephen, > When doing diagnostic function, it is useful to have a ability to iterate > over all > memzones. > You can already access all memzones through rte_eal_get_configuration()->mem_config.memzone[idx]. Best regards, Anatoly Burakov DPDK SW Engineer

[dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation

2014-05-06 Thread Burakov, Anatoly
Hi David, > Actually, if we don't care where memory is allocated, we can at least try to > have the more common setup work properly (i.e. spread memory allocations > based on used cores). > I can see no usual setup where you want to use cores on a socket while having > all memory on another

[dpdk-dev] [PATCH 5/5] add FILE arguement to debug functions

2014-05-06 Thread Burakov, Anatoly
Hi Stephen, > The DPDK dump functions are useful for remote debugging of an > applications. But when application runs as a daemon, stdout > is typically routed to /dev/null. > > Instead change all these functions to take a stdio FILE * handle > instead. An application can then use

[dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation

2014-05-06 Thread Burakov, Anatoly
Hi Thomas, > Having --socket-mem option to explicitly configure NUMA is OK. > Having -m option for simple configuration is OK. Exactly. No explicit requirements - use -m option. Explicit socket requirements - use --socket-mem option. > So I don't understand why we shouldn't do this

[dpdk-dev] DMAR errors when running testpmd

2014-05-07 Thread Burakov, Anatoly
Hi Tomasz It looks like you have your kernel booted with iommu=on. Please check your /proc/cmdline to make sure you didn't accidentally selected the wrong bootloader entry. > We're trying to run testpmd application on HP Proliant DL380P Gen 8 server. > We've enabled SR-IOV in BIOS and set

[dpdk-dev] DMAR errors when running testpmd

2014-05-07 Thread Burakov, Anatoly
Hi Tomasz, Your words: > We've enabled SR-IOV in BIOS and set appropriate flags when booting kernel > (iommu=pt intel_iommu=on) Your other words: > Yes I do have iommu=on set when booting kernel. Here lies your mistake :-) Boot your kernel with iommu to "pt" (iommu=pt intel_iommu=on) and

[dpdk-dev] DMAR errors when running testpmd

2014-05-07 Thread Burakov, Anatoly
Hi Tomasz, > > Here lies your mistake :-) Boot your kernel with iommu to "pt" (iommu=pt > intel_iommu=on) and everything will work. Thje "pt" option enables IOMMU > only for VM's while "on" sets up your whole system to work through IOMMU > (including host devices). However, both of these

[dpdk-dev] DMAR errors when running testpmd

2014-05-07 Thread Burakov, Anatoly
Hi Tomasz, > 2. dmesg messages appear only when I invoke "start tx_first" in testpmd app > (so only when I try to send some packets) Does receiving packets work? I would assume it doesn't, but just making sure. Best regards, Anatoly Burakov DPDK SW Engineer

  1   2   >