From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1176F42D73; Fri, 30 Jun 2023 09:13:51 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DF19E40EDB; Fri, 30 Jun 2023 09:13:50 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id AE1854021F for ; Fri, 30 Jun 2023 09:13:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688109229; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vtediUcIF8YGf4f7tSoL6Tzk9noM3AxNpxGE5WUoc18=; b=CgmmGBNaU7EbHE4su3tPfzCcM+lomU91LQe6zp9NduPQ50wPrg80BbS97th26wwcz85Jha QYjmDR/tZLYzh3YAAYfBLWRhFdKQlohrQNXtzMfBnAa5aOAQAFFJOhge/7nNHMyEWS/7As z2WXIxfPYSm1gZop8N1m/29gceQK54s= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-481-iWO9iub-PSmLTmItBXKVOw-1; Fri, 30 Jun 2023 03:13:47 -0400 X-MC-Unique: iWO9iub-PSmLTmItBXKVOw-1 Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-262e2cb725eso1279379a91.0 for ; Fri, 30 Jun 2023 00:13:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688109226; x=1690701226; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vtediUcIF8YGf4f7tSoL6Tzk9noM3AxNpxGE5WUoc18=; b=Q0cdCpKeZuTmOamqCjV+T5TwLzZdNt8wNLz4PCEJ5jpFkv1YtzQ0NausWb/9lumhGr c0PdPPS3FUqzFfXACjQ/24UJ5BqbkEz+ohFPe6WkpSd4t/epvOnri14O2U1Q56EY3s0Q uDxkYARd7b9GnE3X3OoIxV/Q44c3Mjh4VChZMqJCJU/x/cZbhmfa2MUwL5kbwzXifUTO Nm7Zld95XwD7FBzJYDuewpYuvlEG2+qbMvY+wG6wCt5IByvqEF/MVDv0vop45HYm21SB OxEblrfGQvgnmSarVRzKEEIPLTfnEFZKbTJ0rxe4HpZnLjaqucSUxvtf50HqtjWnFVcs 4aPA== X-Gm-Message-State: AC+VfDyZNG2w9YolAKSnnG8k4D5YNlnl8ciQY9FKpmuPVXhtmZqg78oT FcpExkVmty2eH/Mn6qTZQaregrEvyBC6jdC0jujvOKduDiEcKHb+T1cOO3f66r9AVuQMytzdtvn cINNsp7C6QnvU5VwmwXc= X-Received: by 2002:a17:90a:6983:b0:263:161c:9e9c with SMTP id s3-20020a17090a698300b00263161c9e9cmr8604386pjj.12.1688109226558; Fri, 30 Jun 2023 00:13:46 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5/fQA23z/J9gnSIjqQit5ewMbiHk8cMbIzV7T/DvvBKAbRM4hLSjKxplbZaaV2B6Rcz64CUwEHxvD/8uEQ00I= X-Received: by 2002:a17:90a:6983:b0:263:161c:9e9c with SMTP id s3-20020a17090a698300b00263161c9e9cmr8604367pjj.12.1688109226286; Fri, 30 Jun 2023 00:13:46 -0700 (PDT) MIME-Version: 1.0 References: <20230629135839.974700-1-david.marchand@redhat.com> <4981207.a9HWlOh95j@thomas> <2246452.o7ts2hSHzF@thomas> <0f62a3b9-9884-2892-50a0-e2d01fb37894@amd.com> In-Reply-To: From: David Marchand Date: Fri, 30 Jun 2023 09:13:34 +0200 Message-ID: Subject: Re: [PATCH] ethdev: fix Tx queue mask endianness To: Ferruh Yigit Cc: Thomas Monjalon , Ori Kam , Andrew Rybchenko , Kiran Kumar K , dev@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Jun 30, 2023 at 9:00=E2=80=AFAM David Marchand wrote: > > On Thu, Jun 29, 2023 at 6:14=E2=80=AFPM Ferruh Yigit wrote: > > > > On 6/29/2023 4:42 PM, Thomas Monjalon wrote: > > > 29/06/2023 17:40, David Marchand: > > >> On Thu, Jun 29, 2023 at 5:31=E2=80=AFPM Thomas Monjalon wrote: > > >>> 29/06/2023 15:58, David Marchand: > > >>>> - .tx_queue =3D RTE_BE16(0xffff), > > >>>> + .tx_queue =3D 0xffff, > > >>> > > >>> As I said in an earlier comment about the same issue, > > >>> UINT16_MAX would be better. > > >> > > >> I don't mind updating (or maybe Ferruh can squash this directly ?) b= ut > > >> there are lots of uint16_t fields initialised with 0xffff in this sa= me > > >> file. > > > > > > It can be made in a separate patch for all occurences. > > > First I would like to get some comments, what do you prefer > > > between 0xffff and UINT16_MAX? > > > > > > > Both works, no strong opinion, I am OK with 0xffff, > > > > The variable we are setting is '*_mask', and main point of the value > > used is to have all bits set, and 0xff.. usage highlights it. > > > > Not for UINT16_MAX, but for wider variables, it is easier to make > > mistake and put wrong number of 'f', using 'UINTxx_MAX' macro can > > prevent this mistake, this is a benefit. > > > > > > And I think consistency matters more, so if you prefer 'UINTxx_MAX', > > lets stick to it. > > > > I can update above in next-net, but as far as I understand we can have = a > > patch to fix all occurrences. > > Given that we are considering unsigned integers, is there something > wrong with using (typeof(var)) -1 ? Or maybe get inspiration from what the Linux kernel does :-) Like GENMASK(). --=20 David Marchand