netdev - Re: [PATCH net-next 6/6] sched: Eliminate use of flow_keys in sch

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Mar 2015 11:34:54 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Florian Westphal <fw@...len.de>
Subject: Re: [PATCH net-next 6/6] sched: Eliminate use of flow_keys in sch_sfq

On Mon, Mar 2, 2015 at 11:28 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> On Mon, 2015-03-02 at 08:25 -0800, Tom Herbert wrote:
>
>> One other possibility is that with the txhash changes we can rehash
>> individual connections that are sourced from the host. I was planning
>> to do this on too many TCP retransmits to try to get a different ECMP
>> path (type of source routing), but we could also do this periodically
>> or based on request from qdisc. ooo_okay could be taken into account
>> to avoid OOO packets.
>
> About locally generated traffic, skb->txhash potential uses would be
>
> 1) Somewhat spray txhash on the wire (Hmmm...)
>    Hard to do that with regular IPv4/tcp traffic, or quite hacky.
>    (like VLAN spraying...)
>
Spraying would be quite easy by modulating txhash from TCP and using
either  UDP encapsulation like GUE or IPv6 flow labels. Only problem
is that this would constantly be changing rxhash at the receiver for
the connection, although flow labels might 'just work' with IPv6
Toeplitz in NICs.

> 2.1) Slave selection on bonding driver
> 2.2) TX queue selection on multiqueue NIC.
>
>     In this model (way different than XPS), then skb->ooo_okay is of
>     no use :
>
>     In both cases, if you change skb->txhash after congestion event,
>     you do not care of reorders anyway. They are going to be generated
>     most probably because of different paths.
>
>
>
--
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