> -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
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
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.
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
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: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
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 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(
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
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
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
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
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_
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 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.
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
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
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
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
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
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.
>
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
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
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
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
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
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
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/
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
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
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
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
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
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 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
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
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
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 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
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
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
41 matches
Mail list logo
