rxhash has been renamed to hash. In 3.14 and newer, we can use
skb_set_hash().
Signed-off-by: Aaro Koskinen
---
lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c | 3 ++-
lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff
Neil, John,
I think we all want the same thing: simple and generic APIs.
2014-04-14 10:10, John W. Linville:
> On Mon, Apr 14, 2014 at 03:45:31PM +0200, Thomas Monjalon wrote:
> > From the user's point of view, it must be possible to create some virtual
> > devices instead of using real ones. Tha
Hi Meir,
(2014/04/13 19:21), Meir Tseitlin wrote:
> The problem is that in 30% of the cases data packet enters the path of
> control packet instead of expected answer. Which probably means that after
> my packet type check, the mbuf is overwritten before handled properly.
If you are using DPDK-1.5
On 04/14/2014 03:12 PM, Burakov, Anatoly wrote:
>> 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 comment
Hi John,
2014-04-14 09:20, John W. Linville:
> On Sat, Apr 12, 2014 at 08:05:22AM +0200, Thomas Monjalon wrote:
> > 11/04/2014 20:08, Richardson, Bruce :
> > > The ring PMD is probably best treated separately from the other PMDs as
> > > it's not really a device poll-mode driver. Instead, it's a g
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 bla
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.
Signed-off-by: Anato
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
---
lib/librte_eal/linuxapp/eal/eal_pci.c | 92 -
1 file changed, 46 insertions(+), 46 deletio
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 factorize code.
Si
Hello Anatoly,
I think we might want to start a discussion on what should be done by the eal
and what should be done by the drivers themselves. But this can be done later.
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
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
Print the maximum lcore(s) as configured, and the number of lcore(s) detected
on eal cpu init as debug info besides the not separate detected/not-detected
lcore info.
Signed-off-by: Wang Sheng-Hui
---
lib/librte_eal/linuxapp/eal/eal_lcore.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
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 need
Ok, I think I figured it out - this issue was partly my fault.
I do work with 1.6r0 and I also use Pcap driver.
Pcap driver still contains bug which does not properly release all packets
in rte_eth_tx_burst, causing application to run out of memory. I addressed
this problem wrongly by manually rel
On Mon, Apr 14, 2014 at 03:45:31PM +0200, Thomas Monjalon wrote:
> Hi John,
>
> 2014-04-14 09:20, John W. Linville:
> > On Sat, Apr 12, 2014 at 08:05:22AM +0200, Thomas Monjalon wrote:
> > > 11/04/2014 20:08, Richardson, Bruce :
> > > > The ring PMD is probably best treated separately from the oth
On Mon, Apr 14, 2014 at 03:45:31PM +0200, Thomas Monjalon wrote:
> Hi John,
>
> 2014-04-14 09:20, John W. Linville:
> > On Sat, Apr 12, 2014 at 08:05:22AM +0200, Thomas Monjalon wrote:
> > > 11/04/2014 20:08, Richardson, Bruce :
> > > > The ring PMD is probably best treated separately from the oth
On Sat, Apr 12, 2014 at 08:05:22AM +0200, Thomas Monjalon wrote:
> Hi Bruce,
>
> 11/04/2014 20:08, Richardson, Bruce :
> > From: Neil Horman
> > > On Fri, Apr 11, 2014 at 06:18:08PM +0200, Thomas Monjalon wrote:
> > > > It seems that your patch is not removing
> > > > rte_eth_ring_pair_create/rte_
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 inform
On Mon, 14 Apr 2014 08:57:54 +
"Burakov, Anatoly" wrote:
> 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
19 matches
Mail list logo
