netdev - Re: ingress policying for realtime protocol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <555F369B.2000703@mojatatu.com>
Date:	Fri, 22 May 2015 10:00:59 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	Cong Wang <cwang@...pensource.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: ingress policying for realtime protocol

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html