DPDK patches and discussions
 help / color / mirror / Atom feed
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).