netdev - Re: [net-next PATCH v3 3/5] net: Enable Tx queue selection based on Rx queues

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 6 Jun 2018 12:08:02 -0700
From:   "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        Amritha Nambiar <amritha.nambiar@...el.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Hannes Frederic Sowa <hannes@...essinduktion.org>,
        Tom Herbert <tom@...bertland.com>
Subject: Re: [net-next PATCH v3 3/5] net: Enable Tx queue selection based on
 Rx queues


On 6/6/2018 11:56 AM, Willem de Bruijn wrote:
> On Tue, Jun 5, 2018 at 4:38 AM, Amritha Nambiar
> <amritha.nambiar@...el.com> wrote:
>> This patch adds support to pick Tx queue based on the Rx queue(s) map
>> configuration set by the admin through the sysfs attribute
>> for each Tx queue. If the user configuration for receive queue(s) map
>> does not apply, then the Tx queue selection falls back to CPU(s) map
>> based selection and finally to hashing.
>>
>> Signed-off-by: Amritha Nambiar <amritha.nambiar@...el.com>
>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@...el.com>
>> ---
>>   int sysctl_tcp_max_orphans __read_mostly = NR_FILE;
>>
>> @@ -5574,6 +5575,7 @@ void tcp_finish_connect(struct sock *sk, struct sk_buff *skb)
>>          if (skb) {
>>                  icsk->icsk_af_ops->sk_rx_dst_set(sk, skb);
>>                  security_inet_conn_established(sk, skb);
>> +               sk_mark_napi_id(sk, skb);
>>          }
> This and the call below should be in a standalone patch, as the mark
> changes are not rxq-xps specific. Is the additional earlier marking really
> required?

The additional earlier marking in tcp_finish_connect() allows a client app to do
SO_INCOMING_NAPI_ID after a a connect() call to get the right queue association
for a socket.

The marking in tcp_conn_request() allows syn-ack to go on the right tx-queue
associated with the queue on which syn is received.


>
> I would separate out the entire rxq caching with sk_rx_queue_mapping from
> the refactoring of get_xps_queue. The two changes are quite independent.
>
>>          tcp_init_transfer(sk, BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB);
>> @@ -6402,6 +6404,7 @@ int tcp_conn_request(struct request_sock_ops *rsk_ops,
>>          tcp_rsk(req)->snt_isn = isn;
>>          tcp_rsk(req)->txhash = net_tx_rndhash();
>>          tcp_openreq_init_rwin(req, sk, dst);
>> +       sk_mark_rx_queue(req_to_sk(req), skb);