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
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
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
, 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
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
==
../../../../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:
>
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
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
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,
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
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
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'
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
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
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)
>
>
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
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,
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
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
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
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
, 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
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
23 matches
Mail list logo