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:   Wed, 6 Jun 2018 15:13:14 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Cc:     Amritha Nambiar <amritha.nambiar@...el.com>,
        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 Wed, Jun 6, 2018 at 3:08 PM, Samudrala, Sridhar
<sridhar.samudrala@...el.com> wrote:
>
> 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 understand the intent. My question really is whether it is needed.
Marking has been slightly lossy in this regard in the past, not
necessarily as an oversight. I don't mean to make that call here,
but it's worth discussion and its own patch.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ