netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Murali Karicheri <m-karicheri2@ti.com>,
	Vladimir Oltean <olteanv@gmail.com>
Cc: "netdev\@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: taprio testing - Any help?
Date: Mon, 14 Oct 2019 16:39:58 -0700	[thread overview]
Message-ID: <871rve5229.fsf@linux.intel.com> (raw)
In-Reply-To: <45d3e5ed-7ddf-3d1d-9e4e-f555437b06f9@ti.com>

Murali Karicheri <m-karicheri2@ti.com> writes:
>
> My expectation is as follows
>
> AAAAAABBBBBCCCCCDDDDDEEEEE
>
> Where AAAAA is traffic from TC0, BBBBB is udp stream for port 10000
> CCCCC is stream for port 20000, DDDDD for 30000 and EEEEE for 40000.
> Each can be max of 4 msec. Is the expection correct? At least that
> is my understanding.

Your expectation is correct.

>
> But what I see is alternating packets with port 10000/20000/30000/40000
> at the wireshark capture and it doesn't make sense to me. If you
> look at the timestamp, there is nothing showing the Gate is honored
> for Tx. Am I missing something?

Remember that taprio (in software mode) has no control after the packet
is delivered to the driver. So, even if taprio obeys your traffic
schedule perfectly, the driver/controller may decide to send packets
according to some other logic.

>
> The tc stats shows packets are going through specific TC/Gate
>
> root@am57xx-evm:~# tc -d -p -s qdisc show dev eth0
> qdisc taprio 100: root refcnt 9 tc 5 map 0 1 2 3 4 4 4 4 4 4 4 4 4 4 4 4
> queues offset 0 count 1 offset 1 count 1 offset 2 count 1 offset 3 count 
> 1 offset 4 count 1
> clockid TAI offload 0   base-time 0 cycle-time 0 cycle-time-extension 0 
> base-time 1564768921123459533 cycle-time 20000000 cycle-
> time-extension 0
>          index 0 cmd S gatemask 0x1 interval 4000000
>          index 1 cmd S gatemask 0x2 interval 4000000
>          index 2 cmd S gatemask 0x4 interval 4000000
>          index 3 cmd S gatemask 0x8 interval 4000000
>          index 4 cmd S gatemask 0x10 interval 4000000
>
>   Sent 80948029 bytes 53630 pkt (dropped 0, overlimits 0 requeues 0)
>   backlog 0b 0p requeues 0
> qdisc pfifo 0: parent 100:5 limit 1000p
>   Sent 16184448 bytes 10704 pkt (dropped 0, overlimits 0 requeues 0)
>   backlog 0b 0p requeues 0
> qdisc pfifo 0: parent 100:4 limit 1000p
>   Sent 16184448 bytes 10704 pkt (dropped 0, overlimits 0 requeues 0)
>   backlog 0b 0p requeues 0
> qdisc pfifo 0: parent 100:3 limit 1000p
>   Sent 16184448 bytes 10704 pkt (dropped 0, overlimits 0 requeues 0)
>   backlog 0b 0p requeues 0
> qdisc pfifo 0: parent 100:2 limit 1000p
>   Sent 16184448 bytes 10704 pkt (dropped 0, overlimits 0 requeues 0)
>   backlog 0b 0p requeues 0
> qdisc pfifo 0: parent 100:1 limit 1000p
>   Sent 16210237 bytes 10814 pkt (dropped 0, overlimits 0 requeues 0)
>   backlog 0b 0p requeues 0
>
> Also my hardware queue stats shows frames going through correct queues.
> Am I missing something?
>

What I usually see in these cases, are that the borders (from A to B,
for example) are usually messy, the middle of each entry are more well
behaved.

But there are things that could improve the behavior: reducing TX DMA
coalescing, reducing the number of packet buffers in use in the
controller, disabling power saving features, that kind of thing.

If you are already doing something like this, then I would like to know
more, that could indicate a problem.

[...]

> I am on a 4.19.y kernel with patches specific to taprio
> backported. Am I missing anything related to taprio. I will
> try on the latest master branch as well. But if you can point out
> anything that will be helpful.
>

[...]

> lcpd/ti-linux-4.19.y) Merged TI feature connectivity into
> ti-linux-4.19.y

I can't think of anything else.

>
>> 
>> Regards,
>> -Vladimir
>> 

Cheers,
--
Vinicius

  parent reply	other threads:[~2019-10-14 23:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 19:35 taprio testing - Any help? Murali Karicheri
2019-10-11 20:12 ` Vinicius Costa Gomes
2019-10-11 20:56   ` Murali Karicheri
2019-10-11 21:26     ` Vinicius Costa Gomes
2019-10-13 21:10       ` Vladimir Oltean
2019-10-14 15:33         ` Murali Karicheri
2019-10-14 16:18           ` taprio testing with multiple streams Murali Karicheri
2019-10-14 23:39           ` Vinicius Costa Gomes [this message]
2019-10-16 17:02             ` taprio testing - Any help? Murali Karicheri
2019-10-16 17:14               ` Murali Karicheri
2019-10-16 17:22                 ` Murali Karicheri
2019-10-16 20:32               ` Vinicius Costa Gomes
2019-10-17 13:56                 ` Murali Karicheri
2019-10-17 19:32                   ` Vinicius Costa Gomes
2019-10-17 21:02                     ` Murali Karicheri
2019-10-17 22:26                       ` Murali Karicheri
2019-10-14 23:14         ` Vinicius Costa Gomes

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=871rve5229.fsf@linux.intel.com \
    --to=vinicius.gomes@intel.com \
    --cc=m-karicheri2@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    /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).