[dpdk-dev] generic load balancing

Prashant, I assume your use case is not of one IP/UDP/TCP - or if it is, you are dealing with a single tuple that is not evenly distributed. You have a few options with the NIC that I can think of. 1) Use a single core to RX each port's frames and use your own software solution to RR to worker

[dpdk-dev] generic load balancing

6:16 AM To: Benson, Bryan; Stephen Hemminger Cc: dev at dpdk.org Subject: RE: [dpdk-dev] generic load balancing Hi Bryan, Regarding your 1st point, the single core becomes the rx bottleneck which is clearly not desirable. I am not sure regarding how to use the stuff you mentioned in 2nd point, is

[dpdk-dev] PCI device mapping to socket

All, Does anyone know of a way I can find out which socket a PCI device/bridge is tied up to? I have looked into dmidecode and lspci to no avail, but I may be missing something. We are looking at putting multiple NICs into a single dual socket server. This is so that I can tie specific NIC po

[dpdk-dev] RX checksum offloading

All, Has anyone had any experience with hardware checksum offloads not working? It appears that the combination of settings we are using in our application may be the crux of the issue, as offloading test-pmd application in csum mode correctly identifies bad packets via the ol_flags. I am a bi

[dpdk-dev] RX checksum offloading

All, The receive checksum issue seems to be caused by using a RX_FREE_THRESH value that is 32 or larger, as validated by the test-pmd application. I used 2 different packet types - bad IP checksum sent to port 0 and bad tcp checksum to port 1. The way I was sending the packets did not vary betwe

[dpdk-dev] RX checksum offloading

________ From: dev [dev-boun...@dpdk.org] on behalf of Benson, Bryan Sent: Wednesday, November 06, 2013 7:09 PM To: dev at dpdk.org Subject: Re: [dpdk-dev] RX checksum offloading All, The receive checksum issue seems to be caused by using a RX_FREE_THRESH value that

[dpdk-dev] TX IP checksum offloading

Hi Daniel, I posted some findings yesterday that seem relevant. Try using the ol flags when you use an RX free threshold below 32. I am looking into what can be done to fix it for values of 32 and above. http://dpdk.org/ml/archives/dev/2013-November/000724.html Thanks, Bryan Benson

[dpdk-dev] RX checksum offloading

___ From: Thomas Monjalon [thomas.monja...@6wind.com] Sent: Thursday, November 07, 2013 3:44 AM To: Benson, Bryan Cc: dev at dpdk.org; LiuFeng Subject: Re: [dpdk-dev] RX checksum offloading 07/11/2013 10:06, Thomas Monjalon : > 07/11/2013 04:44, Benson, Bryan : > > RX queu

[dpdk-dev] RX checksum offloading

ember 07, 2013 3:44 AM To: Benson, Bryan Cc: dev at dpdk.org; LiuFeng Subject: Re: [dpdk-dev] RX checksum offloading 07/11/2013 10:06, Thomas Monjalon : > 07/11/2013 04:44, Benson, Bryan : > > RX queues=1 - RX desc=1024 - RX free threshold=16 > > > > -- F

[dpdk-dev] 82599 Checksum offloading for UDP

All, We are using RX checksum offloading for L3 and L4 on the 82599 NIC. One odd behavior we have noticed is that UDP packets with a zero UDP checksum are being marked as invalid. The UDP checksum field for IPv4 + UDP is optional. Is there a way to toggle the behavior? I have been reviewing th

[dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?)

Whoa, be careful, we used a custom init function and had a nasty bug because we assumed it was called on mbuf_free as well. The rte_pktmbuf_init function pointer passed into mempool create is only used at pool initialization time, not when an mbuf is freed - A reference to the obj_initi functio