Hi Amit,
On 1/13/2016 11:00 PM, Amit Tomer wrote:
> Hello,
>
>> You can use below patch for l2fwd to send out an arp packet when it gets
>> started.
> I tried to send out arp packet using this patch but buffer allocation
> for arp packets itself gets failed:
>
> m = rte_pktmbuf_alloc(mp);
>
> Re
This patch set add the VxLAN & NVGRE checksum off-load support.
Both RX and TX checksum off-load can be used for VxLAN & NVGRE.
And the VxLAN port can be set, it's implemented in this patch
set either.
Wenzhuo Lu (6):
lib/librte_ether: change function name of tunnel port config
i40e: rename th
The names of function for tunnel port configuration are not
accurate. They're tunnel_add/del, better change them to
tunnel_port_add/del.
As it may be an ABI change if change the names directly, the
new functions are added but not remove the old ones. The old
ones will be removed in the next release
As the names of tunnel port config functions are not
accurate, change them from tunnel_add/del to
tunnel_port_add/del.
And support both the old and new rte ops.
Signed-off-by: Wenzhuo Lu
---
drivers/net/i40e/i40e_ethdev.c | 22 --
1 file changed, 12 insertions(+), 10 deletion
X550 will do VxLAN & NVGRE RX checksum off-load automatically.
This patch exposes the result of the checksum off-load.
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/ixgbe_rxtx.c | 11 ++-
lib/librte_mbuf/rte_mbuf.c | 1 +
lib/librte_mbuf/rte_mbuf.h | 1 +
3 files changed, 12
Add UDP tunnel port add/del support on ixgbe. Now only
support VxLAN port configuration.
Although the VxLAN port has a default value 4789, it can be
changed. We support VxLAN port configuration to meet the
change.
Note, the default value of VxLAN port in ixgbe NICs is 0. So
please set it when using
The patch add VxLAN & NVGRE TX checksum off-load. When the flag of
outer IP header checksum offload is set, we'll set the context
descriptor to enable this checksum off-load.
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/ixgbe_rxtx.c | 52 ++
drivers/net
Signed-off-by: Wenzhuo Lu
---
doc/guides/rel_notes/release_2_3.rst | 8
1 file changed, 8 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst
b/doc/guides/rel_notes/release_2_3.rst
index 99de186..5dce7fb 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel
Could you show what's exists in
/sys/bus/pci/devices/:01:00.0/
Thanks, Michael
On 1/13/2016 6:23 PM, Ankit Jindal wrote:
> Hi,
>
> We are trying to run dpdk on our arm64 based SOC having Intel 10G
> ixgbe PCIe card plugged. While running any test app, we are getting
> following error.
>
>
On Wed, Jan 13, 2016 at 03:52:01PM +0530, Ankit Jindal wrote:
> Hi,
>
> We are trying to run dpdk on our arm64 based SOC having Intel 10G
> ixgbe PCIe card plugged. While running any test app, we are getting
> following error.
>
> EAL: PCI device :01:00.0 on NUMA socket 0
> EAL: probe drive
On 2016/01/12 15:58, Yuanhan Liu wrote:
> v2: - fix a data corruption reported by Qian, due to hdr size mismatch.
> check detailes at ptach 5.
>
> - Add missing config_irq and isr reading support from v1.
>
> - fix comments from v1.
>
> Almost all difference comes from virtio 1.0 are
On Thu, Jan 14, 2016 at 01:27:37PM +0900, Tetsuya Mukawa wrote:
> On 2016/01/12 15:58, Yuanhan Liu wrote:
> > v2: - fix a data corruption reported by Qian, due to hdr size mismatch.
> > check detailes at ptach 5.
> >
> > - Add missing config_irq and isr reading support from v1.
> >
> >
On Wed, Dec 16, 2015 at 12:38 PM, 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 VFs
> can support some kind o
Hi Tetsuya,
On 1/14/2016 12:27 PM, Tetsuya Mukawa wrote:
> On 2016/01/12 15:58, Yuanhan Liu wrote:
> Hi Yuanhan and Jianfeng,
>
> Thanks for great patches.
> I want to use VIRTIO-1.0 feature for my virtio container patch, because
> it will solve 44 bit memory address limitation.
> (So far, legacy
On 2016/01/14 15:09, Tan, Jianfeng wrote:
>
> Hi Tetsuya,
>
> On 1/14/2016 12:27 PM, Tetsuya Mukawa wrote:
>> On 2016/01/12 15:58, Yuanhan Liu wrote:
>> Hi Yuanhan and Jianfeng,
>>
>> Thanks for great patches.
>> I want to use VIRTIO-1.0 feature for my virtio container patch, because
>> it will sol
On Thu, Jan 14, 2016 at 02:09:18PM +0800, Tan, Jianfeng wrote:
...
> I basically agree with you. We have two dimensions here:
>
> legacy modern
> physical virtio device: Use virtio_read_caps_phys() to
> distinguish
> virtual virtio device (Tetsuya): Use virtio
On Tue, Jan 12, 2016 at 03:17:21PM +, Zhang, Helin wrote:
> Hi Matthew
>
> Yes, you have indicated out the key, the power management module has changed
> or upgraded.
> Could you help to try the legacy one to see if it still works, as indicated
> in your link?
I can do this, but according t
On Thu, Jan 14, 2016 at 02:03:55AM -0500, Matthew Hall wrote:
> Yes, let me know how I could help. I don't know very much yet. My machine is
> Skylake Core i7-6700k. Unfortunately I think I am in trouble here, because
> there is no whitepaper on the Intel website for Intel Speed Shift technology
> -Original Message-
> From: Matthew Hall [mailto:mhall at mhcomputing.net]
> Sent: Thursday, January 14, 2016 3:04 PM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Liang, Cunming; Zhou, Danny
> Subject: Re: [dpdk-dev] librte_power w/ intel_pstate cpufreq governor
>
> On Tue, Jan 12, 2016 at
As we have already set up it at virtio_dev_queue_setup(), and a vq
restart will not reset the settings.
Signed-off-by: Yuanhan Liu
---
drivers/net/virtio/virtio_rxtx.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio
v3: - export pci_unmap_device as well; and invoke it at virtio
uninit stage.
- fixed same data corruption bug reported by Qian in simple
rxtx code path.
- move VIRTIO_READ/WRITE_REG_X to virtio_pci.c
v2: - fix a data corruption reported by Qian, due to hdr size mismatch.
virtio_pci.c is a more proper place for pci stuff; virtio_ethdev.c is not.
Signed-off-by: Yuanhan Liu
---
drivers/net/virtio/virtio_ethdev.c | 265 +---
drivers/net/virtio/virtio_pci.c| 270 -
2 files changed, 270 insertions
Introduce struct virtio_pci_ops, to let legacy virtio (v0.95) and
modern virtio (1.0) have different implementation regarding to a
specific pci action, such as read host status.
With that, this patch reimplements all exported pci functions, in
a way like:
vtpci_foo_bar(struct virtio_hw *h
Switch to 64 bit features, that virtio 1.0 supports.
While legacy virtio only supports 32 bit features, here we complain
aloud and quit when trying to setting > 32 bit features for legacy
device.
Signed-off-by: Yuanhan Liu
---
drivers/net/virtio/virtio_ethdev.c | 8
drivers/net/virtio
The mergeable virtio net hdr format has been the standard and the
only virtio net hdr format since virtio 1.0. Therefore, we can
not hardcode hdr_size to "sizeof(struct virtio_net_hdr)" any more
at virtio_recv_pkts(), otherwise, there would be a mismatch of
hdr size from rte_vhost_enqueue_burst() a
Normally we could set RTE_PCI_DRV_NEED_MAPPING flag so that eal will
invoke pci_map_device internally for us. From that point view, there
is no need to export pci_map_device.
However, for virtio pmd driver, which is designed to work without
binding UIO (or something similar first), pci_map_device(
Modern (v1.0) virtio pci device defines several pci capabilities.
Each cap has a configure structure corresponding to it, and the
cap.bar and cap.offset fields tell us where to find it.
Firstly, we map the pci resources by rte_eal_pci_map_device().
We then could easily locate to a cfg structure by
virtio_pci.c become the only file references those macros; move them there.
Signed-off-by: Yuanhan Liu
---
drivers/net/virtio/virtio_pci.c | 19 +++
drivers/net/virtio/virtio_pci.h | 18 --
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/n
On Thu, Jan 14, 2016 at 03:42:50PM +0800, Yuanhan Liu wrote:
> Normally we could set RTE_PCI_DRV_NEED_MAPPING flag so that eal will
> invoke pci_map_device internally for us. From that point view, there
> is no need to export pci_map_device.
>
> However, for virtio pmd driver, which is designed to
On Thu, Jan 14, 2016 at 07:15:51AM +, Zhang, Helin wrote:
> That's disappointing if Skylake is like that. Let's have a learning first,
> and then check if we can fix that. But in addition, DPDK provide interrupt
> based packet receiving mechanism, can it be one of your choice?
Maybe I am wro
On 1/12/2016 2:58 PM, Yuanhan Liu wrote:
> Modern (v1.0) virtio pci device defines several pci capabilities.
[snip]
> +static void
> +modern_notify_queue(struct virtio_hw *hw __rte_unused, struct virtqueue *vq)
> +{
> + modern_write16(1, vq->notify_addr);
> +}
Does virtio 1.0 only supports MMI
On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote:
> On 1/12/2016 2:58 PM, Yuanhan Liu wrote:
> > Modern (v1.0) virtio pci device defines several pci capabilities.
> [snip]
> > +static void
> > +modern_notify_queue(struct virtio_hw *hw __rte_unused, struct virtqueue
> > *vq)
> > +{
> > +
On 1/12/2016 2:58 PM, Yuanhan Liu wrote:
> Modern (v1.0) virtio pci device defines several pci capabilities.
> Each cap has a configure structure corresponding to it, and the
> cap.bar and cap.offset fields tell us where to find it.
>
> Firstly, we map the pci resources by rte_eal_pci_map_device().
On 1/14/2016 3:49 PM, Yuanhan Liu wrote:
> On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote:
>> On 1/12/2016 2:58 PM, Yuanhan Liu wrote:
>>> Modern (v1.0) virtio pci device defines several pci capabilities.
>> [snip]
>>> +static void
>>> +modern_notify_queue(struct virtio_hw *hw __rte_un
On Thu, Jan 14, 2016 at 07:51:08AM +, Xie, Huawei wrote:
> On 1/14/2016 3:49 PM, Yuanhan Liu wrote:
> > On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote:
> >> On 1/12/2016 2:58 PM, Yuanhan Liu wrote:
> >>> Modern (v1.0) virtio pci device defines several pci capabilities.
> >> [snip]
On 1/14/2016 3:58 PM, Yuanhan Liu wrote:
> On Thu, Jan 14, 2016 at 07:51:08AM +, Xie, Huawei wrote:
>> On 1/14/2016 3:49 PM, Yuanhan Liu wrote:
>>> On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote:
On 1/12/2016 2:58 PM, Yuanhan Liu wrote:
> Modern (v1.0) virtio pci device de
On Thu, Jan 14, 2016 at 2:52 PM, Alex Williamson
wrote:
> On Thu, 2016-01-14 at 14:03 +0800, Jike Song wrote:
>> On Wed, Dec 16, 2015 at 12:38 PM, Alex Williamson
>> wrote:
>> >
>> > So it works. Is it acceptable? Useful? Sufficiently complete? Does
>> > it imply deprecating the uio interface
On Thu, Jan 14, 2016 at 08:08:28AM +, Xie, Huawei wrote:
> On 1/14/2016 3:58 PM, Yuanhan Liu wrote:
> > On Thu, Jan 14, 2016 at 07:51:08AM +, Xie, Huawei wrote:
> >> On 1/14/2016 3:49 PM, Yuanhan Liu wrote:
> >>> On Thu, Jan 14, 2016 at 07:47:17AM +, Xie, Huawei wrote:
> On 1/12/20
On 1/14/2016 12:15 PM, Jerin Jacob wrote:
> On Wed, Jan 13, 2016 at 03:52:01PM +0530, Ankit Jindal wrote:
>> Hi,
>>
>> We are trying to run dpdk on our arm64 based SOC having Intel 10G
>> ixgbe PCIe card plugged. While running any test app, we are getting
>> following error.
>>
>> EAL: PCI device 0
On 1/14/2016 4:21 PM, Yuanhan Liu wrote:
> On Thu, Jan 14, 2016 at 08:08:28AM +, Xie, Huawei wrote:
>> On 1/14/2016 3:58 PM, Yuanhan Liu wrote:
>>> On Thu, Jan 14, 2016 at 07:51:08AM +, Xie, Huawei wrote:
On 1/14/2016 3:49 PM, Yuanhan Liu wrote:
> On Thu, Jan 14, 2016 at 07:47:17AM
?-??|???#8Ki(u&??V?$??!f??x?d`P?k??G?%M??"_h7rL?U??
??A?-2??D??1C?Xv??HAuV?T"?|???MXd;?kOwc0?)??vk?E?x?y?u?R???
???X?'Rm
V?
??p??N???;??R?y???T{x?U?,?s!]p`j?7?c???u
T?p[C???I?nh?2B??M?0?E
??(???e?N???g?>?Ai??V?Z?
?:?W???5]~eLv?9?2|?O?v5e?
Sigh... I have just send out v3 ...
On Thu, Jan 14, 2016 at 07:50:00AM +, Xie, Huawei wrote:
> On 1/12/2016 2:58 PM, Yuanhan Liu wrote:
> > +static inline void
> > +modern_write64_twopart(uint64_t val, uint32_t *lo, uint32_t *hi)
> > +{
> > + modern_write32((uint32_t)val, lo);
> > + modern
Hi, Rahul
Just another thought, please consider about it:
Add a new flow type like
#define RTE_ETH_FLOW_IPV6_UDP_EX17
+#define RTE_ETH_FLOW_RAW_PKT 18
Then add a new item in rte_eth_fdir_flow
union rte_eth_fdir_flow {
struct rte_eth_l2_flow l2_flow;
struc
Hello,
> Can you send out how you start this l2fwd program?
This is how, I run l2fwd program.
CMD ["/usr/src/dpdk/examples/l2fwd/build/l2fwd", "-c", "0x3", "-n",
"4","--no-pci",
,"--no-huge","--vdev=eth_cvio0,queue_num=256,rx=1,tx=1,cq=0,path=/usr/src/dpdk/usvhost",
"--", "-p", "0x1"]
I tried p
Hi Stephen,
> > +/* IOMMU types we support */
> > +static const struct vfio_iommu_type iommu_types[] = {
> > + /* x86 IOMMU, otherwise known as type 1 */
> > + { VFIO_TYPE1_IOMMU, "Type 1",
> &vfio_iommu_type1_dma_map},
> > + /* IOMMU-less mode */
> > + { VF
Hello all,
Here is a proposal of a big cleanup in ethdev (cryptodev would have to
follow) and eal structures.
This is something I wanted to do for quite some time and the arrival of
a new bus makes me think we need it.
This is an alternative to what Jan proposed [1].
ABI is most likely broken wi
On Thu, Jan 14, 2016 at 9:45 AM, Jerin Jacob
wrote:
> On Wed, Jan 13, 2016 at 03:52:01PM +0530, Ankit Jindal wrote:
>> Hi,
>>
>> We are trying to run dpdk on our arm64 based SOC having Intel 10G
>> ixgbe PCIe card plugged. While running any test app, we are getting
>> following error.
>>
>> EAL: P
Hi Amit,
On 1/14/2016 5:34 PM, Amit Tomer wrote:
> Hello,
>
>> Can you send out how you start this l2fwd program?
> This is how, I run l2fwd program.
>
> CMD ["/usr/src/dpdk/examples/l2fwd/build/l2fwd", "-c", "0x3", "-n",
> "4","--no-pci",
> ,"--no-huge","--vdev=eth_cvio0,queue_num=256,rx=1,tx=1,c
Hello David,
nice to see that the things are moving...
On Thu, 14 Jan 2016 11:38:16 +0100
David Marchand wrote:
> Hello all,
>
> Here is a proposal of a big cleanup in ethdev (cryptodev would have to
> follow) and eal structures.
> This is something I wanted to do for quite some time and the
Hello,
>
> Not necessary. But if you want to use hugepages inside Docker, use -v option
> to map a hugetlbfs into containers.
I modified Docker command line in order to make use of Hugetlbfs:
CMD ["/usr/src/dpdk/examples/l2fwd/build/l2fwd", "-c", "0x3", "-n",
"4","--no-pci", "--socket-mem","512"
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
> Sent: Wednesday, January 13, 2016 5:26 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] UX Bug in Sphinx HTML Layout for Programming Guide
> (and maybe other guides?)
>
> When you go to this link:
>
2015-11-20 15:17, Wenzhuo Lu:
> Note:
> Release note is not updated for the target of this patch is R2.3.
> Send these patchs in case someone may hit related issues on new
> platforms.
Please update the release notes now.
> Wenzhuo Lu (17):
> ixgbe/base: update README
> ixgbe/base: avoid need
This patch set optimizes DPDK memcpy for AVX512 platforms, to make full
utilization of hardware resources and deliver high performance.
In current DPDK, memcpy holds a large proportion of execution time in
libs like Vhost, especially for large packets, and this patch can bring
considerable benefit
Read CPUID to check if AVX512 is supported by CPU.
Signed-off-by: Zhihong Wang
---
lib/librte_eal/common/include/arch/x86/rte_cpuflags.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_eal/common/include/arch/x86/rte_cpuflags.h
b/lib/librte_eal/common/include/arch/x86/rte_cpufl
Predefine AVX512 macro if AVX512 is enabled by compiler.
Signed-off-by: Zhihong Wang
---
mk/rte.cpuflags.mk | 4
1 file changed, 4 insertions(+)
diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
index 28f203b..19a3e7e 100644
--- a/mk/rte.cpuflags.mk
+++ b/mk/rte.cpuflags.mk
@@ -89,6 +89
Implement AVX512 memcpy and choose the right implementation based on
predefined macros, to make full utilization of hardware resources and
deliver high performance.
In current DPDK, memcpy holds a large proportion of execution time in
libs like Vhost, especially for large packets, and this patch c
Decide alignment unit for memcpy perf test based on predefined macros.
Signed-off-by: Zhihong Wang
---
app/test/test_memcpy_perf.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/app/test/test_memcpy_perf.c b/app/test/test_memcpy_perf.c
index 754828e..73babec 100644
--- a/app/test/test
Hi Jingjing,
On Thursday, January 01/14/16, 2016 at 00:48:17 -0800, Wu, Jingjing wrote:
> Hi, Rahul
>
> Just another thought, please consider about it:
>
> Add a new flow type like
>
> #define RTE_ETH_FLOW_IPV6_UDP_EX17
> +#define RTE_ETH_FLOW_RAW_PKT 18
>
> Then add a new
Hi,
This v4 patch uses vfio-noiommu-way to access virtio-net pci interface.
Tested for arm64 thunderX platform. Patch builds for
x86/i386/arm/armv8/thunderX. Tested with testpmd application.
Refer v3 [1] cover letter for dependancy description:
Step to enable vfio-noiommu mode:
- modprobe vfio-pc
virtio_recv_pkts_vec and other virtio vector friend apis are written for sse/avx
instructions. For arm64 in particular, virtio vector implementation does not
exist(todo).
So virtio pmd driver wont build for targets like i686, arm64. By making
RTE_VIRTIO_INC_VECTOR=n, Driver can build for non-sse/
i686 target config example:
config/defconfig_i686-native-linuxapp-gcc says "Vectorized PMD is not supported
on 32-bit".
So setting RTE_VIRTIO_INC_VECTOR to 'n'.
Signed-off-by: Santosh Shukla
---
config/defconfig_i686-native-linuxapp-gcc |1 +
config/defconfig_i686-native-linuxapp-icc |1
iopl() syscall not supported in linux-arm/arm64 so always return 0 value.
Signed-off-by: Santosh Shukla
Suggested-by: Stephen Hemminger
Acked-by: Jan Viktorin
---
v3->v4:
- moved #ifdef to elseif -> suggested by Stephen.
lib/librte_eal/linuxapp/eal/eal.c |2 ++
1 file changed, 2 insertions
vfio_pci_mmap() try to map all pci bars. ioport region are not mapped in
vfio/kernel so ignore mmaping for ioport.
Signed-off-by: Santosh Shukla
---
v3->v4: per review comment from Stephen and Yuan.
- removed ioport_bar var declaration with in func to top of func
- rearrange log message to fit wi
make sure sys/io.h used only for x86 archs. This fixes build error
arm64/arm case.
Signed-off-by: Santosh Shukla
---
drivers/net/virtio/virtio_pci.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index 47f722a..8b5b031 1
Introducing below api for pci bar space rd/wr. Currently used for
pci iobar rd/wr.
Api's are:
- rte_eal_pci_read_bar
- rte_eal_pci_write_bar
virtio when used for vfio-mode then virtio driver will use these api
to do rd/wr operation on ioport pci bar.
Signed-off-by: Santosh Shukla
---
v3->v4:
-
For vfio case - Use pread/pwrite api to access virtio
ioport space.
Signed-off-by: Santosh Shukla
Signed-off-by: Rizwan Ansari
Signed-off-by: Rakesh Krishnamurthy
---
v3->v4:
- Corrected debug error message for oub_ class of apis
- renamed file from virtio_vfio.h to virtio_vfio_rw.h
- Removed #
So far virtio handle rw access for uio / ioport interface, This patch to extend
the support for vfio interface. For that introducing private struct
virtio_vfio_dev{
- is_vfio
- pci_dev
};
Signed-off-by: Santosh Shukla
---
v3->v4:
- Removed #indef RTE_EAL_VFIO and made it ar
Introducing api to check interface type is vfio or not, if interface is vfio
then update struct virtio_vfio_dev {}.
Those two apis are:
- virtio_chk_for_vfio
- virtio_hw_init_by_vfio
Signed-off-by: Santosh Shukla
---
v3->v4:
- Removed RTE_PCI_DRV_NEED_MAPPING drv flag (as per Review comment from
For non-x86 arch, Compiler will throw build error for in/out apis. Including
dummy api function so to pass build.
Note that: For virtio to work for non-x86 arch - RTE_EAL_VFIO is the only
supported method. RTE_EAL_IGB_UIO is not supported for non-x86 arch.
So, Virtio support for arch and supporte
Enable RTE_LIBRTE_VIRTIO_PMD for armv7/v8 and setting RTE_VIRTIO_INC_VEC=n.
Builds successfully for armv7/v8.
Signed-off-by: Santosh Shukla
---
v2->v4:
- Removed explict setting of VIRTIO_PMD in configs (per review comment from
Jiangbo)
config/defconfig_arm-armv7a-linuxapp-gcc |4 +++-
c
From: Yuanhan Liu
Normally we could set RTE_PCI_DRV_NEED_MAPPING flag so that eal will
invoke pci_map_device internally for us. From that point view, there
is no need to export pci_map_device.
However, for virtio pmd driver, which is designed to work without
binding UIO (or something similar fir
Using mapping api i.e. rte_eal_pci_map_device() to create vfio container, group
id and get the vfio-dev-fd for virtio-net-pci interface. Later vfio_dev_fd used
for virtio device rd/wr operation.
Signed-off-by: Santosh Shukla
---
v3->v4:
- Per stephens comment, removed static driver flag RTE_PCI_X
From: Anatoly Burakov
This commit is adding a generic mechanism to support multiple IOMMU
types. For now, it's only type 1 (x86 IOMMU) and no-IOMMU (a special
VFIO mode that doesn't use IOMMU at all), but it's easily extended
by adding necessary definitions into eal_pci_init.h and a DMA
mapping f
On Wed, Jan 13, 2016 at 02:23:36PM -0800, Stephen Hurd wrote:
> Previously, max_socket was set to the highest numbered socket with
> an enabled lcore. The intent is to set it to the highest socket
> regardless of it being enabled.
>
Can you clarify why this changes is necessary? Is it causing a
On 1/6/2016 8:04 PM, Thomas Monjalon wrote:
> 2016-01-05 08:10, Xie, Huawei:
>> On 10/26/2015 10:06 PM, Xie, Huawei wrote:
>>> On 10/19/2015 1:16 PM, Stephen Hemminger wrote:
This is a tested version of the virtio Tx performance improvements
that I posted earlier on the list, and describe
On Thu, 14 Jan 2016 01:13:18 -0500
Zhihong Wang wrote:
> This patch set optimizes DPDK memcpy for AVX512 platforms, to make full
> utilization of hardware resources and deliver high performance.
>
> In current DPDK, memcpy holds a large proportion of execution time in
> libs like Vhost, especial
Hi,
I am seeing a "Failed to init adminq: -54" or admin queue timeouts
while initializing the admin queue for i40e xl710 intel nic.
(Intel server is a E5-2670)
First things first.
I am running the latest firmware.
The kernel module is not loaded and yes, it works with the i40e kernel
driver.
77 matches
Mail list logo
