Hi,
I am just trying out DPDK in a fedora 18 KVM guest and have an issue when I
am trying l2fwd application.
I am binding eth1, eth2 interfaces using below commands
./igb_uio_bind.py --bind=igb_uio eth1
./igb_uio_bind.py --bind=igb_uio eth2
When I run l2fwd app I get following error
./l2fwd -c
Ajith,
You are missing "-p PORTMASK" command line argument. Since you are binding
two ports to IGB_UIO, you should add -p 0x3 to the command line.
You can check the example command from sample applications user guide.
$ ./build/l2fwd -c 1 -n 4 -- -p 3
Regards,
Vivek
On Fri, Apr 11, 2014 at 9:34
Hi friends,
Even after installing all the required igb drivers for I350 (the device
seems to work perfect on the host machine), am unable to transmit packets
using the same device (on Intel DPDK) using
ret = rte_eth_tx_burst(port_ids[lcore_id], 0, m_pool, burst_size);
At times it might transfer
The name "nonpci_devs" for virtual devices is ambiguous as a physical
device can also be non-PCI (ex: usb, sata, ...). A better name for this
file is "vded" as it only deals with virtual devices.
This patch doesn't introduce any change except renaming.
Signed-off-by: Olivier Matz
---
lib/librte
Instead of having a list of virtual device drivers in EAL code, add an
API to register drivers. Thanks to this new registration method, we can
remove the references to pmd_ring, pmd_pcap and pmd_xenvirt in EAL code.
This also enables the ability to register a virtual device driver as
a shared libra
The registration of an external vdev driver (a .so library) is done in a
function that has the ((constructor)) attribute. This function is called
when dlopen(driver.so) is invoked.
As a result, we need to do the dlopen() before calling
rte_eal_vdev_init() that calls the initialization functions of
Hi,
2014-04-11 11:29, sabu kurian:
> Even after installing all the required igb drivers for I350 (the device
> seems to work perfect on the host machine), am unable to transmit packets
> using the same device (on Intel DPDK) using
Please follow this documentation to setup your environment and do
Hi,
2014-04-10 21:34, Prashant Upadhyaya:
> 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.
This issue is fixed by this commit:
http://dpdk.org/browse/dpdk/
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 see
Hi Anatoly,
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 original issue.
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 or
Hi Hiroshi,
On Thursday, April 03, 2014 07:33:42 AM Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto
>
> The MEMNIC header file should be under Dual BSD/GPL license.
> Put the license text "Dual BSD/GPL" into the file header.
>
> Signed-off-by: Hiroshi Shimamoto
> ---
> common/memnic.h | 1
On Thursday, April 03, 2014 07:34:56 AM Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto
>
> Because DPDK has its own compare and set function to optimize to
> dedicated processor type, use that rte_atomic32_cmpset() instead of
> cmpxchg macro which is specially introduced for MEMNIC.
>
> Sign
On Thursday, April 03, 2014 07:35:50 AM Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto
>
> Same as PMD, there is a race condition between host and guest
> in the guest MEMNIC kernel driver.
>
> Guest PMD Host
> Thread-A Thread-B vSwitch
>
>|idx=0 |idx=0
Hi Friends,
Thanks for the reply.
This is the portion of the code where the I350 fails to send packet:
for(;;){
ret = rte_eth_tx_burst(port_ids[lcore_id], 0, m_pool,
burst_size);
if (unlikely(ret < burst_size)) {
for(j=ret;j<(burst_size-ret);j
To add to my previous mail.
only upto 544 packets are actually sent... then it fails
On Fri, Apr 11, 2014 at 3:34 PM, sabu kurian wrote:
> Hi Friends,
>
> Thanks for the reply.
>
> This is the portion of the code where the I350 fails to send packet:
>
> for(;;){
>
> ret = r
On Fri, Apr 11, 2014 at 09:36:52AM +0200, Olivier Matz wrote:
> Instead of having a list of virtual device drivers in EAL code, add an
> API to register drivers. Thanks to this new registration method, we can
> remove the references to pmd_ring, pmd_pcap and pmd_xenvirt in EAL code.
> This also ena
2014-04-11 09:36, Olivier Matz:
> The name "nonpci_devs" for virtual devices is ambiguous as a physical
> device can also be non-PCI (ex: usb, sata, ...). A better name for this
> file is "vded" as it only deals with virtual devices.
>
> This patch doesn't introduce any change except renaming.
>
The name "nonpci_devs" for virtual devices is ambiguous as a physical
device can also be non-PCI (ex: usb, sata, ...). A better name for this
file is "vdev" as it only deals with virtual devices.
This patch doesn't introduce any change except renaming.
Signed-off-by: Olivier Matz
---
lib/librte
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 a/lib/librte_eal/linuxapp/eal/eal
2014-04-11 13:45, Olivier Matz:
> The name "nonpci_devs" for virtual devices is ambiguous as a physical
> device can also be non-PCI (ex: usb, sata, ...). A better name for this
> file is "vdev" as it only deals with virtual devices.
>
> This patch doesn't introduce any change except renaming.
>
Hi Neil,
2014-04-11 06:49, Neil Horman:
> On Fri, Apr 11, 2014 at 09:36:52AM +0200, Olivier Matz wrote:
> > Instead of having a list of virtual device drivers in EAL code, add an
> > API to register drivers. Thanks to this new registration method, we can
> > remove the references to pmd_ring, pmd_
Hi John,
2014-04-10 10:41, John W. Linville:
> These PMDs were being initialized by the EAL layer, but many apps were
> relying on the return value of rte_pmd_init_all to indicate that
> ethernet interfaces were available for use. Move the initialization of
> the non-PCI PMDs to this centralized
2014-04-11 09:36, Olivier Matz:
> Instead of having a list of virtual device drivers in EAL code, add an
> API to register drivers. Thanks to this new registration method, we can
> remove the references to pmd_ring, pmd_pcap and pmd_xenvirt in EAL code.
> This also enables the ability to register a
2014-04-11 09:36, Olivier Matz:
> The registration of an external vdev driver (a .so library) is done in a
> function that has the ((constructor)) attribute. This function is called
> when dlopen(driver.so) is invoked.
>
> As a result, we need to do the dlopen() before calling
> rte_eal_vdev_init(
On Thursday, April 03, 2014 06:35:06 AM Hiroshi Shimamoto wrote:
> From: Hiroshi Shimamoto
>
> There is a race condition, on transmit to host.
>
> Guest PMD Host
> Thread-A Thread-B vSwitch
>
>|idx=0 |idx=0 |p[0] st!=2
>|cmpxchg ||
>
2014-04-11 11:37, Olivier MATZ:
> On Thursday, April 03, 2014 07:34:56 AM Hiroshi Shimamoto wrote:
> > From: Hiroshi Shimamoto
> >
> > Because DPDK has its own compare and set function to optimize to
> > dedicated processor type, use that rte_atomic32_cmpset() instead of
> > cmpxchg macro which i
2014-04-11 16:41, Olivier MATZ:
> On Thursday, April 03, 2014 06:35:06 AM Hiroshi Shimamoto wrote:
> > From: Hiroshi Shimamoto
> >
> > There is a race condition, on transmit to host.
> >
> > Guest PMD Host
> > Thread-A Thread-B vSwitch
> >
> >|idx=0 |idx=0
2014-04-11 11:41, Olivier MATZ:
> On Thursday, April 03, 2014 07:35:50 AM Hiroshi Shimamoto wrote:
> > From: Hiroshi Shimamoto
> >
> > Same as PMD, there is a race condition between host and guest
> > in the guest MEMNIC kernel driver.
> >
> > Guest PMD Host
> > Thread-A Thre
2014-04-11 11:35, Olivier MATZ:
> Hi Hiroshi,
>
> On Thursday, April 03, 2014 07:33:42 AM Hiroshi Shimamoto wrote:
> > From: Hiroshi Shimamoto
> >
> > The MEMNIC header file should be under Dual BSD/GPL license.
> > Put the license text "Dual BSD/GPL" into the file header.
> >
> > Signed-off-by
On Fri, Apr 11, 2014 at 03:11:56PM +0200, Thomas Monjalon wrote:
> Hi Neil,
>
> 2014-04-11 06:49, Neil Horman:
> > On Fri, Apr 11, 2014 at 09:36:52AM +0200, Olivier Matz wrote:
> > > Instead of having a list of virtual device drivers in EAL code, add an
> > > API to register drivers. Thanks to thi
2014-04-11 11:50, Neil Horman:
> There are still problems with the libraries after Oliviers patch series:
>
> [nhorman at hmsreliant lib]$ ldd librte_pmd_pcap.so
> statically linked
>
> The DSO's built by dpdk are not actually build as shared libraries but
> rather statically linked toget
On Thu, 10 Apr 2014 09:39:35 +
"Burakov, Anatoly" wrote:
> 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 place
1) anywhere on amazon or elsewhere on the cloud.
2) If you have a specific hw configuration that you can buy off the shelf i
would appreciate
One of my pet peeve's is that the device driver config does not abstract
the properties of the Ethernet device. The existing parameters match those
of Intel's Ethernet hardware but not much else. It also makes it hard
to write generic applications. If the application has to query the
device driver
On Fri, Apr 11, 2014 at 06:18:08PM +0200, Thomas Monjalon wrote:
> 2014-04-11 11:50, Neil Horman:
> > There are still problems with the libraries after Oliviers patch series:
> >
> > [nhorman at hmsreliant lib]$ ldd librte_pmd_pcap.so
> > statically linked
> >
> > The DSO's built by dpdk
On Fri, Apr 11, 2014 at 10:33:31AM -0700, Stephen Hemminger wrote:
> One of my pet peeve's is that the device driver config does not abstract
> the properties of the Ethernet device. The existing parameters match those
> of Intel's Ethernet hardware but not much else. It also makes it hard
> to wri
Agree that the patch sets are a step towards fixing that, but there is a lot
more to be done on this. Could we start discussion on what the "ideal"
abstraction should be? I'd like to pool those into a formal proposal that we
can discuss and drive through a series of patches to make that happen.
On Fri, Apr 11, 2014 at 05:57:41PM +, Venkatesan, Venky wrote:
> Agree that the patch sets are a step towards fixing that, but there is a lot
> more to be done on this. Could we start discussion on what the "ideal"
> abstraction should be? I'd like to pool those into a formal proposal that we
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Friday, April 11, 2014 6:45 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 07/11 1/2] vdev: new registration API
>
> On Fri, Apr 11, 2014 at 06:18:08PM +02
On Fri, Apr 11, 2014 at 03:23:27PM +0200, Thomas Monjalon wrote:
> Hi John,
>
> 2014-04-10 10:41, John W. Linville:
> > These PMDs were being initialized by the EAL layer, but many apps were
> > relying on the return value of rte_pmd_init_all to indicate that
> > ethernet interfaces were available
41 matches
Mail list logo
