Netdev List
 help / color / mirror / Atom feed
From: "Nambiar, Amritha" <amritha.nambiar@intel.com>
To: Alexander Duyck <alexander.duyck@gmail.com>,
	Tom Herbert <tom@herbertland.com>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Alexander Duyck <alexander.h.duyck@intel.com>,
	Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	Sridhar Samudrala <sridhar.samudrala@intel.com>,
	Eric Dumazet <edumazet@google.com>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>
Subject: Re: [net-next PATCH v4 3/7] net: sock: Change tx_queue_mapping in sock_common to unsigned short
Date: Tue, 26 Jun 2018 16:54:19 -0700	[thread overview]
Message-ID: <c82eedb4-dd55-0c1d-cf20-89946e38cab4@intel.com> (raw)
In-Reply-To: <CAKgT0UdPWPtmatsWtAGTpEMA_SxEqm4OehD3Obg-mA2noBZtOw@mail.gmail.com>

On 6/25/2018 8:25 PM, Alexander Duyck wrote:
> On Mon, Jun 25, 2018 at 6:34 PM, Tom Herbert <tom@herbertland.com> wrote:
>>
>>
>> On Mon, Jun 25, 2018 at 11:04 AM, Amritha Nambiar
>> <amritha.nambiar@intel.com> wrote:
>>>
>>> Change 'skc_tx_queue_mapping' field in sock_common structure from
>>> 'int' to 'unsigned short' type with 0 indicating unset and
>>> a positive queue value being set. This way it is consistent with
>>> the queue_mapping field in the sk_buff. This will also accommodate
>>> adding a new 'unsigned short' field in sock_common in the next
>>> patch for rx_queue_mapping.
>>>
>>> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
>>> ---
>>>  include/net/sock.h |   10 ++++++----
>>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/net/sock.h b/include/net/sock.h
>>> index b3b7541..009fd30 100644
>>> --- a/include/net/sock.h
>>> +++ b/include/net/sock.h
>>> @@ -214,7 +214,7 @@ struct sock_common {
>>>                 struct hlist_node       skc_node;
>>>                 struct hlist_nulls_node skc_nulls_node;
>>>         };
>>> -       int                     skc_tx_queue_mapping;
>>> +       unsigned short          skc_tx_queue_mapping;
>>>         union {
>>>                 int             skc_incoming_cpu;
>>>                 u32             skc_rcv_wnd;
>>> @@ -1681,17 +1681,19 @@ static inline int sk_receive_skb(struct sock *sk,
>>> struct sk_buff *skb,
>>>
>>>  static inline void sk_tx_queue_set(struct sock *sk, int tx_queue)
>>>  {
>>> -       sk->sk_tx_queue_mapping = tx_queue;
>>> +       /* sk_tx_queue_mapping accept only upto a 16-bit value */
>>> +       WARN_ON((unsigned short)tx_queue > USHRT_MAX);
>>
>>
>> Shouldn't this be USHRT_MAX - 1 ?
> 
> Actually just a ">=" would probably do as well.

Ugh! Will definitely fix this.

> 
>>
>>> +       sk->sk_tx_queue_mapping = tx_queue + 1;
>>>  }
>>>
>>>  static inline void sk_tx_queue_clear(struct sock *sk)
>>>  {
>>> -       sk->sk_tx_queue_mapping = -1;
>>>
>>> +       sk->sk_tx_queue_mapping = 0;
>>
>>
>> I think it's slightly better to define a new constant like NO_QUEUE_MAPPING
>> to be USHRT_MAX. That avoids needing to do the arithmetic every time the
>> value is accessed.

The idea was to have avoid having to make any changes to the callers of
these functions and make this similar to queue_mapping in skbuff with 0
indicating unset and +ve value for set. sk_tx_queue_get returns -1 on
invalid and the callers were validating -ve values.  With
sk_tx_queue_mapping initialized to USHRT_MAX, and having an additional
check in sk_tx_queue_get to return -1 if sk_tx_queue_mapping has
USHRT_MAX, I think I can keep changes minimal and avoid the arithmetic
if that's a more acceptable solution.

>>>
>>>  }
>>>
>>>  static inline int sk_tx_queue_get(const struct sock *sk)
>>>  {
>>> -       return sk ? sk->sk_tx_queue_mapping : -1;
>>> +       return sk ? sk->sk_tx_queue_mapping - 1 : -1;
>>
>>
>> Doesn't the comparison in __netdev_pick_tx need to be simultaneously changed
>> for this?
> 
> This doesn't change the result. It was still -1 if the queue mapping
> is not set. It was just initialized to 0 instead of to -1 so we have
> to perform the operation to get there.
> 
> Also in regards to the comment above about needing an extra operation
> I am not sure it makes much difference.
> 
> In the case of us starting with 0 as a reserved value I think the
> instruction count should be about the same. We move the unsigned short
> into an unsigned in, then decrement, and if the value is non-negative
> we can assume it is valid. Although maybe I should double check the
> code to make certain it is doing what I thought it was supposed to be
> doing.
> 
>>
>>>
>>>
>>>
>>>  }
>>>
>>>  static inline void sk_set_socket(struct sock *sk, struct socket *sock)
>>>
>>

  reply	other threads:[~2018-06-26 23:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-25 18:04 [net-next PATCH v4 0/7] Symmetric queue selection using XPS for Rx queues Amritha Nambiar
2018-06-25 18:04 ` [net-next PATCH v4 1/7] net: Refactor XPS for CPUs and " Amritha Nambiar
2018-06-26 22:53   ` Tom Herbert
2018-06-28  0:47     ` Nambiar, Amritha
2018-06-25 18:04 ` [net-next PATCH v4 2/7] net: Use static_key for XPS maps Amritha Nambiar
2018-06-26 22:54   ` Tom Herbert
2018-06-25 18:04 ` [net-next PATCH v4 3/7] net: sock: Change tx_queue_mapping in sock_common to unsigned short Amritha Nambiar
     [not found]   ` <CALx6S37uFs1shuPmno+L=p_Hyy1Q2qNaK+AqYvrk4HXTApL_Vg@mail.gmail.com>
2018-06-26  3:25     ` Alexander Duyck
2018-06-26 23:54       ` Nambiar, Amritha [this message]
2018-06-26 10:58   ` Willem de Bruijn
2018-06-27  0:00     ` Nambiar, Amritha
2018-06-25 18:04 ` [net-next PATCH v4 4/7] net: Record receive queue number for a connection Amritha Nambiar
2018-06-25 18:04 ` [net-next PATCH v4 5/7] net: Enable Tx queue selection based on Rx queues Amritha Nambiar
2018-06-26  2:04   ` kbuild test robot
2018-06-26 11:04   ` Willem de Bruijn
2018-06-27  0:36     ` Nambiar, Amritha
2018-06-27 10:47       ` Willem de Bruijn
2018-06-28  0:48         ` Nambiar, Amritha
2018-06-25 18:04 ` [net-next PATCH v4 6/7] net-sysfs: Add interface for Rx queue(s) map per Tx queue Amritha Nambiar
2018-06-26 10:55   ` Willem de Bruijn
2018-06-27  0:21     ` Nambiar, Amritha
2018-06-25 18:04 ` [net-next PATCH v4 7/7] Documentation: Add explanation for XPS using Rx-queue(s) map Amritha Nambiar
2018-06-26 22:59   ` Tom Herbert

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=c82eedb4-dd55-0c1d-cf20-89946e38cab4@intel.com \
    --to=amritha.nambiar@intel.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hannes@stressinduktion.org \
    --cc=netdev@vger.kernel.org \
    --cc=sridhar.samudrala@intel.com \
    --cc=tom@herbertland.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox