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 4880D42D73; Fri, 30 Jun 2023 09:00:54 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1D46B406B5; Fri, 30 Jun 2023 09:00:54 +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 9FDF04021F for ; Fri, 30 Jun 2023 09:00:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688108452; 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=W+88CVv/yANNOcpv50tVyWFkY7vpSEwT/T7WJ0DANuA=; b=fBfNcqoJuHsl+cwCA6Mw2+2fPcDL+hYhUVvos0VEtwerQk3w5HdBnSNmafeU40f3qJIIJn 0KdkomsIS2J4AyV6e4ScmVineErr33cxYGludiN0lc/UudEdeLzY9BgiUQ3GOtWyVyWFOC 4bwNmGwh7wQSkb4Wsd8/1q9419bDxD4= Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-67-S4N59CHGMByEDbkT9Cf33g-1; Fri, 30 Jun 2023 03:00:50 -0400 X-MC-Unique: S4N59CHGMByEDbkT9Cf33g-1 Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-263047f46f4so1255098a91.1 for ; Fri, 30 Jun 2023 00:00:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688108449; x=1690700449; 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=W+88CVv/yANNOcpv50tVyWFkY7vpSEwT/T7WJ0DANuA=; b=RF6ZDeRd57eTB4ZeR+AWLh78rM1mFASp9JM7hGU9D+zdZAYY2ioA4Uc8m9EUWJ/tx1 3aeNedy3DBTlhLJMJazdyIVhRRoCnd1dLTaYmSctajMeE/xdVewaTEiDkYH4EIsZIDEy uBONSgLULgC0EhCafBAmt5QJk7Mr+i0/Zhwm8AzoJcuDbBYyzy57uJRhAbZMPn/s2hAN HCIo+nTd0UHVpPSRxwIU9zvUScKKk4fJL+RIWFtMgK/Y+Ea01EtvBTckR/wMhvp1fhlR MeJmdauUZA81hGJV6XiDP78KbHVArfCRulhjUlGsyGt4Z7m5zbp+QglLGs2TYxM5zaig 493Q== X-Gm-Message-State: AC+VfDwXei3zuILSeEK5eLI3t/OU5VPUPFZiwunooe8n34c3IS6ytMKt FR75hC+AK/o9hJisqIg7ZMf6pfWLQbKwz1534YI0ZtqvmHeFp58NCMh6v0wYtQbVT+b7h7q7l2U ITHJsPw/NdSrbe9Zf1lg= X-Received: by 2002:a17:90b:797:b0:25d:d224:9fb9 with SMTP id l23-20020a17090b079700b0025dd2249fb9mr7613969pjz.24.1688108449253; Fri, 30 Jun 2023 00:00:49 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6kF1rOyE9aeJJ+apN1JO453ZVc5SypmOt52LSK4Q7g4OEWsEPaU+8wxyBm1cCPd0W6g0nimA9XZrGQx21SPkU= X-Received: by 2002:a17:90b:797:b0:25d:d224:9fb9 with SMTP id l23-20020a17090b079700b0025dd2249fb9mr7613950pjz.24.1688108448923; Fri, 30 Jun 2023 00:00:48 -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: <0f62a3b9-9884-2892-50a0-e2d01fb37894@amd.com> From: David Marchand Date: Fri, 30 Jun 2023 09:00:37 +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 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 ?) but > >> there are lots of uint16_t fields initialised with 0xffff in this same > >> 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 ? We could define a new macro to hide this ugly detail. --=20 David Marchand