Hi Dom,
Was about to suggest that you used this [1] but I see you already figured it
up.
Let me know what’s wrong with the echo app once you get a chance to debug it.
Regards,
Florin
[1] https://gerrit.fd.io/r/c/vpp/+/25286
> On Feb 19, 2020, at 2:14 PM, dchons via Lists.Fd.Io
> wrote:
>
Hi again,
For what it's worth, I added a hack in src/plugins/dpdk/device/init.c and set
xd->port_conf.rxmode.offloads |= DEV_RX_OFFLOAD_UDP_CKSUM , and now I have:
vpp# sh hardware-interfaces
Name Idx Link Hardware
TenGigabitEthernet5/0/0 1 down TenGigabitEtherne
Hi Florin,
Thanks for the suggestion. It looks like in my case
*ip4_local_l4_csum_validate* is being called:
Breakpoint 1, ip4_local_l4_csum_validate (vm=0x7fffb4ecef40, p=0x10026d9980,
ip=0x10026d9a8e, is_udp=1 '\001',
error=0x7fffb517b1d8 "\016\023", good_tcp_udp=0x7fffb517b19d
"\177\001\001
Hi Dom,
Now that you mention it, it’s the same for my nics. Nonetheless, the packets
that reach ip4-local are marked as having a valid l4 checksum. Check in
ip4_local_check_l4_csum_x2 and ip4_local_check_l4_csum if
ip4_local_l4_csum_validate is called or not. If not, there’s no extra overhead
[Edited Message Follows]
** Edit **: Corrected typo, udp-cksum not active in rx-offloads, but is active
in tx-offloads
Hi Florin,
Thanks for the response. I'm not so concerned about the packet drops (as you
point out it is to be expected), however increasing the number of rx
descriptors did h
Hi Florin,
Same NIC on both machines:
root# dpdk-devbind --status
Network devices using DPDK-compatible driver
:05:00.0 'Ethernet 10G 2P X520 Adapter 154d' drv=uio_pci_generic
unused=ixgbe
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages se
Hi Don,
Inline.
> On Feb 19, 2020, at 11:54 AM, dchons via Lists.Fd.Io
> wrote:
>
> Hi Florin,
>
> Thanks for the response. I'm not so concerned about the packet drops (as you
> point out it is to be expected), however increasing the number of rx
> descriptors did help a lot, so thank you
Hi Florin,
Thanks for the response. I'm not so concerned about the packet drops (as you
point out it is to be expected), however increasing the number of rx
descriptors did help a lot, so thank you very much for that!
I'm still at around 6.5 Gbps, "sh session verbose" shows the following:
*Clie
Hi Dom,
UDP is without any flow/congestion control. That is, there is nothing to push
back on the sender when it over drives the receiver. Increasing the number of
rx descriptors probably helps a bit but unless the rx nic is faster, I don’t
know if there’s anything else that could avoid the dr
Hello,
I've been trying to do some basic performance testing on 20.01 using the
vpp_echo application, and while I'm getting the expected performance with TCP,
I'm not quite able to achieve what I would expect with UDP. The NICs are 10G
X520, and on TCP I get around 9.5 Gbps, but with UDP I get
*What: *Standard updates and upgrade
* Jenkins
o OS and security updates
o Upgrade
o Plugin updates
* Nexus
o OS updates
* Jira
o OS updates
* Gerrit
o OS updates
* Sonar
o OS updates
* OpenGrok
o OS updates
*When: *2020-02-20 1900 UTC
Coverity run failed today.
Current number of outstanding issues are 1
Newly detected: 0
Eliminated: 1
More details can be found at
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15463): ht
> On Feb 19, 2020, at 2:02 AM, Neale Ranns via Lists.Fd.Io
> wrote:
>
>
> Hi Chris,
>
> Adding an API to dump a single route would be a welcome addition to the API.
Ok, I'll do that then.
For tables of things (at least in ip.api) I'm noticing a pattern of
xADD, xDEL, xDUMP
I think the API
13 matches
Mail list logo
