From: Andy Duan <fugang.duan@nxp.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Stefan Agner <stefan@agner.ch>,
"festevam@gmail.com" <festevam@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"netdev-owner@vger.kernel.org" <netdev-owner@vger.kernel.org>
Subject: RE: FEC on i.MX 7 transmit queue timeout
Date: Mon, 8 May 2017 02:13:25 +0000 [thread overview]
Message-ID: <AM4PR0401MB2260D9D293EE8A37B93554F6FFEE0@AM4PR0401MB2260.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20170505122330.GA23432@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch> Sent: Friday, May 05, 2017 8:24 PM
>To: Andy Duan <fugang.duan@nxp.com>
>Cc: Stefan Agner <stefan@agner.ch>; festevam@gmail.com;
>netdev@vger.kernel.org; netdev-owner@vger.kernel.org
>Subject: Re: FEC on i.MX 7 transmit queue timeout
>
>> No, it is not workaround. As i said, quque1 and queue2 are for AVB
>> paths have higher priority in transmition.
>
>Does this higher priority result in the low priority queue being starved? Is that
>why the timer goes off? What happens when somebody does use AVB. Are
>we back to the same problem? This is what seems to make is sounds like a
>work around, not a fix.
>
> Andrew
Yes, queue0 may be blocked by queue1 and queue2, then the queue0 watchdog time maybe triggered.
If somebody use AVB quque1 and queue2, the remaining bandwidth is for queue0, for example, in 100Mbps system, quque1 cost 50Mbps bandwidth and queue2 cost 50Mbps bandwidth for audio and video streaming, then queue0 (best effort) has 0 bandwidth that limit user case cannot have asynchronous frames (IP(tcp/udp)) on networking. Of course these is extreme case.
In essentially, asynchronous frames (IP) go queue0 for the original design. To do these just implement .ndo_select_queue() callback in driver like fsl tree.
Regards,
Andy
next prev parent reply other threads:[~2017-05-08 2:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-18 19:46 FEC on i.MX 7 transmit queue timeout Stefan Agner
2017-04-19 2:24 ` Andy Duan
2017-04-19 5:01 ` Stefan Agner
2017-04-19 5:28 ` Andy Duan
2017-04-19 5:56 ` Stefan Agner
2017-04-19 8:45 ` Andy Duan
2017-04-19 23:15 ` Stefan Agner
2017-04-21 2:48 ` Andy Duan
2017-05-04 1:21 ` Stefan Agner
2017-05-04 3:08 ` Andy Duan
2017-05-04 21:36 ` Stefan Agner
2017-05-05 2:03 ` Andy Duan
2017-05-05 2:09 ` Stefan Agner
2017-05-05 2:44 ` Andy Duan
2017-05-05 12:23 ` Andrew Lunn
2017-05-08 2:13 ` Andy Duan [this message]
2017-05-08 18:22 ` Stefan Agner
2017-05-09 10:35 ` Andy Duan
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=AM4PR0401MB2260D9D293EE8A37B93554F6FFEE0@AM4PR0401MB2260.eurprd04.prod.outlook.com \
--to=fugang.duan@nxp.com \
--cc=andrew@lunn.ch \
--cc=festevam@gmail.com \
--cc=netdev-owner@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=stefan@agner.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.