From: Karthikraj palanichamy <karthikraj.palanichamy@veryxtech.com>
To: dev@dpdk.org, users@dpdk.org
Cc: "gokilavani.anbazhagan@veryxtech.com"
<gokilavani.anbazhagan@veryxtech.com>,
"sumithra.subramanian@veryxtech.com"
<sumithra.subramanian@veryxtech.com>,
"Binu Nadarajan (Veryx Technologies)"
<binu.nadarajan@veryxtech.com>,
Nagaraj <nagarajan.boominathan@veryxtech.com>,
Arunsiva <arunsiva.aathinarayanan@veryxtech.com>,
"'Selvaraj (Veryx Technologies)'"
<selvaraj.balasubramanian@veryxtech.com>
Subject: [dpdk-dev] Drop pkts whenever port link status changes
Date: Fri, 23 Jun 2017 16:50:44 +0530 [thread overview]
Message-ID: <594CF98C.5080703@veryxtech.com> (raw)
Hi!
I am using DPDK to develop a delay measurement application.
I put a timestamp in the packet and call rte_eth_tx_burst(). The
receiving end would just loopback the packet.
Using the timestamp that I had put, and the current time, I am able to
calculate the delay in the network.
But when the link goes down and up, I am observing huge delay.
This is because the packets which are placed in the ring just before the
link got down, are transmitted once the link is up.
E.g. If it took 500ms between link down and up, I will get (current time
- timestamp) as 500ms.
Do you have a solution to solve this? Is there any way we can instruct
to drop the packets when link is down (or) cleanup the queue and start
fresh when the link is up?
Note : I have registered a link status callback function.
(rte_eth_dev_callback_register(portid, RTE_ETH_EVENT_INTR_LSC,
linkStatusCheck, NULL)).
So I can know the link status as earlier as possible and prevent doing
rte_eth_tx_burst() if link is down.
But still in case of race scenarios, pkts placed in the ring before the
link got down may get transmitted after the link gets up.
Thanks,
Karthik
DISCLAIMER: Privileged and/or Confidential information may be
contained in this message. If you are not the addressee of this message,
you may not copy, use or deliver this message to anyone. In such
event,you should destroy the message and kindly notify the sender by
reply e-mail.
It is understood that opinions or conclusions that do not relate to the
official business of the company are neither given nor endorsed by the
company.
reply other threads:[~2017-06-23 11:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=594CF98C.5080703@veryxtech.com \
--to=karthikraj.palanichamy@veryxtech.com \
--cc=arunsiva.aathinarayanan@veryxtech.com \
--cc=binu.nadarajan@veryxtech.com \
--cc=dev@dpdk.org \
--cc=gokilavani.anbazhagan@veryxtech.com \
--cc=nagarajan.boominathan@veryxtech.com \
--cc=selvaraj.balasubramanian@veryxtech.com \
--cc=sumithra.subramanian@veryxtech.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).