From: Jamal Hadi Salim <jhs@mojatatu.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Cong Wang <cwang@twopensource.com>,
netdev <netdev@vger.kernel.org>
Subject: Re: ingress policying for realtime protocol
Date: Fri, 22 May 2015 10:00:59 -0400 [thread overview]
Message-ID: <555F369B.2000703@mojatatu.com> (raw)
In-Reply-To: <20150521185831.GC24769@pengutronix.de>
On 05/21/15 14:58, Uwe Kleine-König wrote:
> Hello,
>
> My picture of the network stack might be wrong, but if the ethernet
> driver queues say 5 packets to the network stack and the fourth is a MRP
> packet than a priorization that makes the fourth packet processed first
> would be nice.
>
> If there is no queue and the first packet is processed before the
> ethernet driver has a chance to hand over the second obviously there is
> no benefit from using a prio queue because it would always only contain
> a single packet.
>
Yes. If these packets arrived at about the same time then i think
good MRP friendly hardware should hand over the MRP packet first ahead
of some of the other ones. Then you really dont need a queue.
Otherwise you are compensating for this hardware not being smart enough.
Only scenario i can think of where a queue would be useful is if
the (host) system is overloaded. I think NAPI would pull up to N
packets and queue them to something like ifb. Later when the tasklet
is run they would be re-injected back to the stack.
> The 100kbit limit was found by starting with a higher limit and
> decrement while scp still made the MRP hiccup. Now what's wrong: It's
> annoying that other traffic is cut down that much.
>
I think from that perspective I like Eric's script, except i would
modify it to use simple pfifo i.e shaping is not really necessary
but as you experiment you may reach a different conclusion.
> There is only a single port involved but that one is connected to a
> Marvell switch. So the packets all come in on eth0 but the userspace
> application that handles the MRP stuff still knows on which port of the
> switch the packet came in. Also the blocking of a port is done with
> configuration of the switch. Does this answer your question?
>
Hrm. So eth0 is a management/control port? I thought this was a speacial
MRP kind of hardware. And if am not mistaken the switch is just driven
by classical STP state of blocking/forwarding etc. So other than the
control packets showing up on out of band port this looks and smells
like STP. i.e this is just vanilla off the shelf switch ASIC with no
MRP specialization.
cheers,
jamal
next prev parent reply other threads:[~2015-05-22 14:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-19 21:11 ingress policying for realtime protocol Uwe Kleine-König
2015-05-20 23:46 ` Cong Wang
2015-05-21 0:30 ` Eric Dumazet
2015-05-21 1:47 ` Cong Wang
2015-05-21 1:53 ` Eric Dumazet
2015-05-21 1:59 ` Cong Wang
2015-05-21 2:32 ` Eric Dumazet
2015-05-21 7:07 ` Uwe Kleine-König
2015-05-21 13:36 ` Jamal Hadi Salim
2015-05-21 18:58 ` Uwe Kleine-König
2015-05-22 14:00 ` Jamal Hadi Salim [this message]
2015-05-21 14:04 ` Eric Dumazet
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=555F369B.2000703@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=cwang@twopensource.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
/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.