DPDK usage discussions
 help / color / mirror / Atom feed
From: "Freynet, Marc (Nokia - FR)" <marc.freynet@nokia.com>
To: EXT Masoud Moshref Javadi <masood.moshref.j@gmail.com>,
	"users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] high jitter in dpdk kni
Date: Mon, 25 Jan 2016 08:29:42 +0000	[thread overview]
Message-ID: <CD8753ABF4FE4F46A702A199B8D2F9C691A35AE4@FR712WXCHMBA15.zeu.alcatel-lucent.com> (raw)
In-Reply-To: <CAKCrth1oYjqkuWA8RQBRKzLgBdOv=ug_aDOH=bp3CyHjRVTBXg@mail.gmail.com>

Hi,

Some months ago we had a problem with the KNI driver.
Our DPDK application forwards to the Linux kernel through KNI the SCTP PDU received from the Eth NIC.
In one configuration, the SCTP port Source and Destination were constant on all SCTP connections.
This is a known SCTP issue as in the multi processor environment, the SCTP stack uses the port Source and Destination to hash the processor that will run the SCTP context in the kernel.
SCTP cannot use the IP address as a hash key thanks to the SCTP multi homing feature.

As all SCTP PDU on all SCTP connections where processed by the same Core, this creates a bottle neck and the KNI interface starts creating Jitter and even was losing PDU when sending the SCTP PDU to the IP Linux kernel stack.

I am wondering if in a previous release it you not be possible to add KNI a kind of load sharing with different queues on different cores to forward the received PDU to the IP Linux stack.

​"Bowl of rice will raise a benefactor, a bucket of rice will raise a enemy.", Chinese proverb.

FREYNET Marc
Alcatel-Lucent France
Centre de Villarceaux
Route de Villejust
91620 NOZAY France

Tel:  +33 (0)1 6040 1960
Intranet: 2103 1960

marc.freynet@nokia.com

-----Original Message-----
From: users [mailto:users-bounces@dpdk.org] On Behalf Of EXT Masoud Moshref Javadi
Sent: samedi 23 janvier 2016 15:18
To: users@dpdk.org
Subject: [dpdk-users] high jitter in dpdk kni

I see jitter in KNI RTT. I have two servers. I run kni sample application on one, configure its IP and ping an external interface.

sudo -E build/kni -c 0xaaaa -n 4 -- -p 0x1 -P --config="(0,3,5)"
sudo ifconfig vEth0 192.168.1.2/24
ping 192.168.1.3

This is the ping result:
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=1.93 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=0.907 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=3.15 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=1.96 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=3.95 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=2.90 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=64 time=0.933 ms

The ping delay between two servers without kni is 0.170ms.
I'm using dpdk 2.2.

Any thought on how to keep KNI delay predictable?

Thanks

  reply	other threads:[~2016-01-25  8:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-23 14:17 Masoud Moshref Javadi
2016-01-25  8:29 ` Freynet, Marc (Nokia - FR) [this message]
2016-01-25 13:15   ` Masoud Moshref Javadi
2016-01-25 13:43     ` Andriy Berestovskyy
2016-01-25 13:49       ` Masoud Moshref Javadi
2016-01-25 14:15         ` Jay Rolette
2016-01-25 14:43     ` Freynet, Marc (Nokia - FR)
2016-01-25 13:37 ` Jay Rolette

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CD8753ABF4FE4F46A702A199B8D2F9C691A35AE4@FR712WXCHMBA15.zeu.alcatel-lucent.com \
    --to=marc.freynet@nokia.com \
    --cc=masood.moshref.j@gmail.com \
    --cc=users@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).