[dpdk-dev] eth dev doesn't free mbufs for 82575EB

2014-06-19 Thread Helmut Sim
Thanks, it has the same effect as my changeee i found the lost packets issue... it was related to my app implementation (a bug with increasing the number of segments at the nb_segs variable). anyway thanks. On Wed, Jun 11, 2014 at 7:18 PM, Thomas Monjalon wrote: > 2014-05-30 15:44, Hel

[dpdk-dev] eal_parse_coremask fails on SIGILL

2014-06-24 Thread Helmut Sim
Hi, I need some help to understand the following issue. I am building the DPDK with make install T=x86_64-default-linuxapp-gcc and it works well on my machine. However when testing it on my virtual machine (ubuntu 14.04 server guest n xen hv) it fails for SIGILL: here is the relevant gdb output f

[dpdk-dev] eal_parse_coremask fails on SIGILL

2014-06-24 Thread Helmut Sim
one more detail, i am using dpdk-1.6.0r1 On Tue, Jun 24, 2014 at 6:05 PM, Helmut Sim wrote: > Hi, > > I need some help to understand the following issue. > > I am building the DPDK with make install T=x86_64-default-linuxapp-gcc and > it works well on my machine. > Howev

[dpdk-dev] eal_parse_coremask fails on SIGILL

2014-06-24 Thread Helmut Sim
, Bruce < bruce.richardson at intel.com> wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Helmut Sim > > Sent: Tuesday, June 24, 2014 8:08 AM > > To: dev at dpdk.org > > Subject: Re: [dpdk-dev] eal_parse

[dpdk-dev] fail to bind '82541GI Gigabit Ethernet Controller' to IGB_UIO driver

2014-05-14 Thread Helmut Sim
Hi, I am new to dpdk. I built the dpdk-1.6.0r1 and even was able to compile the apps. Then I am trying to bind my NIC to the dpdk application: #modprobe uio # #insmod x86_64-default-linuxapp-gcc/kmod/igb_uio.ko # # ./tools/pci_unbind.py --status Network devices using IGB_UIO driver ==

[dpdk-dev] fail to bind '82541GI Gigabit Ethernet Controller' to IGB_UIO driver

2014-05-14 Thread Helmut Sim
../../../../module/igb_uio --w--- 1 root root 4096 May 14 17:48 new_id --w--- 1 root root 4096 May 14 17:48 remove_id --w--- 1 root root 4096 May 14 17:39 uevent --w--- 1 root root 4096 May 14 17:48 unbind Thanks! On Wed, May 14, 2014 at 5:45 PM, Thomas Monjalon wrote: >

[dpdk-dev] fail to bind '82541GI Gigabit Ethernet Controller' to IGB_UIO driver

2014-05-14 Thread Helmut Sim
d a 82575EB_FIBER_SERDES, how can i tell if mine is one of them? it is a Dual Port PCI-E X4 Gigabit Server Adapter 575T ( http://www.winyao.com/en/product_view_20_117.html). Thanks On Wed, May 14, 2014 at 5:53 PM, Helmut Sim wrote: > Thanks Thomas for your quick answer. > > Meanti

[dpdk-dev] fail to bind '82541GI Gigabit Ethernet Controller' to IGB_UIO driver

2014-05-18 Thread Helmut Sim
I am on my way to validate it... Is there a pre-defined test or checklist for validating a NIC? Thanks On Fri, May 16, 2014 at 1:15 AM, Thomas Monjalon wrote: > Hi Sim, > > 2014-05-14 18:44, Helmut Sim: > > I made the required change in order to support the 82541GI chipset and

[dpdk-dev] roundtrip delay

2014-05-25 Thread Helmut Sim
Hi, what is the way to optimize the round trip delay of a packet? i.e. receiving a packet and then resending it back to the network in a minimal time, assuming the rx and tx threads are on a continuous loop of rx/tx. Thanks,

[dpdk-dev] eth dev doesn't free mbufs for 82575EB

2014-05-30 Thread Helmut Sim
Hi all, I am trying to verify that the 82575EB NIC functions well. The file rte_pci_dev_ids.h includes the following lines: #ifdef RTE_PCI_DEV_USE_82575EB_COPPER RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82575EB_COPPER) #endif so I defined the RTE_PCI_DEV_USE_82575EB_COPPER and h

[dpdk-dev] two tso related questions

2014-12-15 Thread Helmut Sim
Hi, While working on TSO based solution I faced the following two questions: 1. is there a maximum pkt_len to be used with TSO?, e.g. let's say if seg_sz is 1400 can the entire segmented pkt be 256K (higer than 64K) ?, then the driver gets a list of chanined mbufs while the first mbuf is set to T

[dpdk-dev] two tso related questions

2014-12-16 Thread Helmut Sim
Alex Markuze wrote: > > > > On Mon, Dec 15, 2014 at 10:20 PM, Helmut Sim wrote: >> >> Hi, >> >> While working on TSO based solution I faced the following two questions: >> >> 1. >> is there a maximum pkt_len to be used with TSO?, e.g. let'

[dpdk-dev] two tso related questions

2014-12-17 Thread Helmut Sim
thanks. i will check this On Tue, Dec 16, 2014 at 4:04 PM, Alex Markuze wrote: > > > > On Tue, Dec 16, 2014 at 2:24 PM, Helmut Sim wrote: >> >> Thanks Alex, >> >> So i probably miss something... >> what you are saying is correct for IP segmentation wh

[dpdk-dev] phantom old packets received in new mbuf

2014-07-06 Thread Helmut Sim
Hi All, I face a very strange behavior. I do: rte_eth_rx_burst(port[i].portid, 0, pkts_burst, MAX_PKT_BURST) then I reassemble the received UDP segments into one packet (i used the ip_reassembly example), manipulate its content and send it back to the network after fragmenting the packet. This wo

[dpdk-dev] phantom old packets received in new mbuf

2014-07-16 Thread Helmut Sim
a basic issue I'm pretty sure it is a kind of configuration problem. any idea? Thanks in advance, On Sun, Jul 6, 2014 at 6:19 PM, Helmut Sim wrote: > Hi All, > > I face a very strange behavior. > I do: > rte_eth_rx_burst(port[i].portid, 0, pkts_burst, MAX_PKT_BURST) > >

[dpdk-dev] phantom old packets received in new mbuf

2014-07-16 Thread Helmut Sim
after its previous one. this is also the case in other problematic cases. is there any way to configure ethernet IFG (Interf Frame Gap)? Thanks, On Wed, Jul 16, 2014 at 3:18 PM, Olivier MATZ wrote: > Hello Helmut, > > > 2014-07-16 13:56, Helmut Sim: > >> then i see that fr

[dpdk-dev] phantom old packets received in new mbuf

2014-07-16 Thread Helmut Sim
taterr=0x3 pkt_len=146 PMD: eth_igb_recv_pkts(): port_id=0 queue_id=0 rx_tail=276 nb_hold=4 nb_rx=4 IM_LOG_VFLOWCOM: input: START_10 58640 IM_LOG_VFLOWCOM: input: START_10 58641 IM_LOG_VFLOWCOM: input: START_10 58642 IM_LOG_VFLOWCOM: input: START_10 58643 On Wed, Jul 16, 2014 at 3:36 PM,

[dpdk-dev] phantom old packets received in new mbuf

2014-07-17 Thread Helmut Sim
new packet...). All of my six 82541gi NICs behaves at the same way... :( maybe it is a driver issue (will look for it latter). Thank for your advices and assistance, On Wed, Jul 16, 2014 at 4:22 PM, Helmut Sim wrote: > The CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG and CONFIG_RTE_LIBRTE_MBUF_DE

[dpdk-dev] how to control receive timer for the wthresh?

2014-07-27 Thread Helmut Sim
Hi all, Is there, on dpdk 1.6, an API for controlling the receive timer (EITR) expiration of the wthresh on the NICs? when setting, for example, .wthresh to 4 and transmitting 7 packets to the application, then the last 3 packets remains in the on-chip-buffer for too long and are written to the ho

[dpdk-dev] using hash table in a MP environment

2014-06-11 Thread Helmut Sim
one more simple way would be to assign the desired hash function to the hash_func in the rte_hash structure returned by rte_hash_find_existing call at the secondary initialization phase. that way there is no difference between a primary or a secondary process. Regards, On Tue, Jun 10, 2014 at 3

[dpdk-dev] two tso related questions

2015-01-04 Thread Helmut Sim
solution to make sure it also support lower lengths for other NICs. Any idea? Sim On Wed, Dec 17, 2014 at 3:02 PM, Olivier MATZ wrote: > Hi Helmut, > > On 12/17/2014 08:17 AM, Helmut Sim wrote: > >> While working on TSO based solution I faced the following two question

[dpdk-dev] two tso related questions

2015-01-04 Thread Helmut Sim
, 2015 at 11:57 AM, Alex Markuze wrote: > > > On Sun, Jan 4, 2015 at 10:50 AM, Helmut Sim wrote: > >> Hi Alex and Olivier, >> >> Alex, I made the test and the segmentation is not at the IP level (i.e. >> each packet ip total length indicated the mss length

[dpdk-dev] hpet alternative when using qemu-kvm

2015-03-10 Thread Helmut Sim
Hi All, using my dpdk application on a guest over qemu-kvm (version 1.5.3) I fail to initialize the hpet. this returns failure due to "Device or resource busy". This is also the case when accessing the "/dev/hpet", so obviously this is not a dpdk issue. I couldn't resolve this issue at the host/g