Hi all,
Does anyone know if there is a way to measure the round trip latency
between pktgen and l2fwd? If not, is there a way to add timestamps to
measure latency? Our current setup is: Machine A runs DPDK pktgen and is
connected back-to-back with Machine B running l2fwd.
Thank you.
Jun
28/01/2014 02:16, Sangjin Han:
> >> It would be nice if I can bypass set_tsc_freq_from_cpuinfo() in
> >> set_tsc_freq().
> >
> > I think it would not solve the problem because your clock is varying and
> > the TSC calibration must be updated accordingly with different values by
> > core.
[...]
>
Add a file app/test/test_kvargs.c that checks the rte_kvargs API.
The test passes:
RTE>>kvargs
== test valid case ==
== test invalid case ==
PMD: Error parsing device, invalid key
Test OK
I also tested that rte_eth_pcap runs with the following arguments:
./app/testpmd -c 0x15 -n 3 -
In rte_kvargs_process() and rte_kvargs_count(), if the key_match
argument is NULL, process all entries.
Signed-off-by: Olivier Matz
---
lib/librte_kvargs/rte_kvargs.c | 4 ++--
lib/librte_kvargs/rte_kvargs.h | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/lib/librte_kva
This argument can be useful when rte_kvargs_process() is called with
key=NULL, in this case the handler is invoked for all entries of the
kvlist.
Signed-off-by: Olivier Matz
---
lib/librte_kvargs/rte_kvargs.c | 2 +-
lib/librte_kvargs/rte_kvargs.h | 2 +-
lib/librte_pmd_pcap/rte_eth_pc
The "value" argument is read-only and should be const.
Signed-off-by: Olivier Matz
---
lib/librte_kvargs/rte_kvargs.h | 2 +-
lib/librte_pmd_pcap/rte_eth_pcap.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/librte_kvargs/rte_kvargs.h b/lib/librte_kv
When we match a key in is_valid_key() and rte_kvargs_process(), do a
strict comparison (strcmp()) instead of using strstr(s1, s2) which tries
a find s1 in s2. This old behavior could lead to unexpected match, for
instance "cola" match "chocolate".
Surprisingly, no patch was needed on rte_kvargs_co
Remove the rte_kvargs_add_pair() function whose only role was to check
if a key is duplicated. Having duplicated keys is now allowed by kvargs
API.
Also replace rte_strsplit() by more a standard function strtok_r() that
is easier to understand for people already knowing the libc. It also
avoids us
Before the patch, a call to rte_kvargs_tokenize() resulted in a call to
strdup() to allocate a modifiable copy of the argument string. This
string was never freed, excepted in the error cases of
rte_kvargs_tokenize() where rte_free() was wrongly called instead of
free(). In other cases, freeing thi
This value was not very useful as the size of the table is fixed (equals
RTE_KVARGS_MAX).
By the way, the memset in the initialization function was wrong (size
too short). Even if it was not really an issue since we rely on the
"count" field, it is now fixed by this patch.
Signed-off-by: Olivier
Now that rte_kvargs is a generic library, there is no need to have an argument
for the driver name in rte_kvargs_tokenize() and rte_kvargs_parse()
prototypes. This argument was only used to log the driver name in case of
error. Instead, we can add a log in init function of pmd_pcap and pmd_ring.
S
The rte_kvargs library is a reworked copy of rte_eth_pcap_arg_parser,
so it provides the same service. Therefore we can use it and remove the
code of rte_eth_pcap_arg_parser.
Signed-off-by: Olivier Matz
---
lib/librte_pmd_pcap/Makefile | 8 +-
lib/librte_pmd_pcap/rte_eth_pcap.
Copy the code from rte_eth_pcap_arg_parser.[ch], without any functional
modifications, only:
- rename functions and structure
- restyle (indentation)
- add comments (doxygen style)
- add "const" or "static" attributes, remove unneeded "inline"
Signed-off-by: Olivier Matz
---
config/defconfig_i68
The topic of this patchset is to add a new rte_kvargs library that
can be used as a helper to parse key/value arguments. The code will
be based on rte_eth_pcap_arg_parser and reworked with documentation
and tests. It also fix some minor issues of the original code.
These commits will allow another
28/01/2014 16:26, Olivier Matz:
> When the user specifies --create-uio-dev in dpdk eal start options, the
> DPDK will create the /dev/uioX instead of waiting that a program does it
> (which is usually hotplug).
>
> This option is useful in embedded environments where there is no hotplug
> to do th
24/01/2014 16:31, Olivier Matz:
> Add a new function pci_get_uio_dev() that parses /sys/bus/pci/devices
> to get the uio device associated with a PCI device. This patch just
> moves some code that was in pci_uio_map_resource() in the new function
> without any functional change.
>
> Thanks to this
When the user specifies --create-uio-dev in dpdk eal start options, the
DPDK will create the /dev/uioX instead of waiting that a program does it
(which is usually hotplug).
This option is useful in embedded environments where there is no hotplug
to do the work.
Signed-off-by: Olivier Matz
---
l
Hi Pravin,
Yes, it is a good integration with http://dpdk.org
Few feature questions:
- what's about the vNIC supports (toward the guests)?
- what's about IPsec support (VxLAN over IPsec for instance)?
I do not understand how your patch will solve those 2 cases.
>>> This is based a patch fr
24/01/2014 16:31, Olivier Matz:
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -357,6 +358,7 @@ eal_usage(const char *prgname)
> " --"OPT_NO_PCI" : disable pci\n"
> " --"OPT_NO_HPET" : disable hpet\n"
> " --"OPT_
On 01/28/2014 12:00 AM, Michael Quicquaro wrote:
> Dmitry,
> I cannot thank you enough for this information. This too was my main
> problem. I put a "small" unmeasured delay before the call to
> rte_eth_rx_burst() and suddenly it starts returning bursts of 512
> packets vs. 4!!
> Best Regards,
hi !
can someone please tell me whether the DPDK provides any method to handle
below
a. account the packet drops at NIC level ? is there any interrupt raised by
DPDK for the same ?
b. to check fifo errors ?
c. way to check rx and tx in sync
Tx,
-SB
On Tue, Jan 28, 2014 at 7:54 AM, Thomas Graf wrote:
> On 01/28/2014 03:47 PM, Vincent JARDIN wrote:
>>
>> Hi Pravin,
>>
>> Yes, it is a good integration with http://dpdk.org
>>
>> Few feature questions:
>>- what's about the vNIC supports (toward the guests)?
>>- what's about IPsec support
On Tue, Jan 28, 2014 at 7:48 AM, Thomas Graf wrote:
> On 01/28/2014 02:48 AM, pshelar at nicira.com wrote:
>>
>> From: Pravin B Shelar
>>
>> Following patch adds DPDK netdev-class to userspace datapath.
>> Approach taken in this patch differs from Intel? DPDK vSwitch
>> where DPDK datapath switch
TSC has lots of platform related issues. It is not guaranteed sync'd across
physical
packages and AMD boxes have lots of problems.
Why does delay_ms not just use nanosleep() and let the OS worry about it?
On a related note, I have found that putting the worker (non master) threads
into real time
Hi Vincent,
On Tue, Jan 28, 2014 at 6:47 AM, Vincent JARDIN
wrote:
> Hi Pravin,
>
> Yes, it is a good integration with http://dpdk.org
>
> Few feature questions:
> - what's about the vNIC supports (toward the guests)?
> - what's about IPsec support (VxLAN over IPsec for instance)?
> I do not
Some more discovery.
That flag PKT_TX_VLAN_PKT eventually send the following command to the
chips (ixgbe_xmit_pkts(), tx_desc_vlan_flags_to_cmdtype()) . Is this
actually adding a VLAN tag during tx ?
#define IXGBE_ADVTXD_DCMD_VLE IXGBE_TXD_CMD_VLE /* VLAN pkt
enable */
#define IXGBE
26 matches
Mail list logo