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 38AF1A0A02; Fri, 16 Apr 2021 23:47:41 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B7FD7161D46; Fri, 16 Apr 2021 23:47:40 +0200 (CEST) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by mails.dpdk.org (Postfix) with ESMTP id AADC7161D34 for ; Fri, 16 Apr 2021 23:47:39 +0200 (CEST) Received: by mail-qt1-f169.google.com with SMTP id m16so21257587qtx.9 for ; Fri, 16 Apr 2021 14:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QhurXPGvz+/1A9GgTgm800QHgUzqogSomIoVCOvoaQ8=; b=Ska+rurgs40ZsaSmYXdh9sBQT3E+BngQ0qH2nX/isTC5du8rwC6TDWf09tkKz3mzVf nZloxwfGMD4fGN1E5sPLwmgt0qZa5d/ryrA5kFtHU+CPMCOW2HxhOyY54NW5Y7wZBslA KM56tq+gFKDNKx9VTkz8rWT1ErcQ97vzJAEEI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QhurXPGvz+/1A9GgTgm800QHgUzqogSomIoVCOvoaQ8=; b=GRpQQnx/ydzyHmLQ8SA6CZDqiX8q8hYn6GwEamKxN0qftYWIGtjKnGeUQfcwli2BZZ 9KsQecG3IKL3o1OJ5tqS+diXyDgBuM6cU9B76qHo9GdOkkfpg0eTOVkgb9lC0i+147aQ XsB/8ZFhjXLjC8Rz91HYnkyp62GCzduDDrGnWCsvj4MBzO7ZUURHWX7wqCrVAtxztqrF I7s283L20EQkyH6qKgvSutyjvU8pBaSwlyrWXSqapxQad0q5T8xV8ctz8jOqPSwyfaTO rV1sCueOQlyqEHbZF53daKY2wIQtcBxJ4SpQzJGvJk/0KnPIE/ebMogWZx58M16DwXk8 8OyQ== X-Gm-Message-State: AOAM532KQSthbH+pmV6bXTMJ8RODvCRuvS5BC/HurJ5ru6U7lveIkTOa q3fyZNrXsKLDex2DqUaSAA9/d8X8w98/2CrkVVtGnA== X-Google-Smtp-Source: ABdhPJyhRfJE+VxBTsY2PjVnwa6ZrnmSDuoFwehPRx4jESOnIP7XUhOuJMYPeoGG0gMWLvaF/LLjNBrRsW/A3sTtz8o= X-Received: by 2002:ac8:5e0b:: with SMTP id h11mr1195095qtx.194.1618609658734; Fri, 16 Apr 2021 14:47:38 -0700 (PDT) MIME-Version: 1.0 References: <1618062393-205611-1-git-send-email-bingz@nvidia.com> <1618504877-95597-1-git-send-email-bingz@nvidia.com> <1618504877-95597-2-git-send-email-bingz@nvidia.com> In-Reply-To: From: Ajit Khaparde Date: Fri, 16 Apr 2021 14:47:22 -0700 Message-ID: To: Bing Zhao Cc: Ori Kam , NBU-Contact-Thomas Monjalon , "ferruh.yigit@intel.com" , "andrew.rybchenko@oktetlabs.ru" , "dev@dpdk.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c3e4eb05c01ded95" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH v2 1/2] ethdev: introduce conntrack flow action and item 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 Sender: "dev" --000000000000c3e4eb05c01ded95 Content-Type: text/plain; charset="UTF-8" > > > + > > > +/** > > > + * @warning > > > + * @b EXPERIMENTAL: this structure may change without prior > > notice > > > + * > > > + * Configuration parameters for each direction of a TCP > > connection. > > > + */ > > > +struct rte_flow_tcp_dir_param { > > > + uint32_t scale:4; /**< TCP window scaling factor, 0xF to > > disable. */ > > > + uint32_t close_initiated:1; /**< The FIN was sent by this > > direction. */ > > > + /**< An ACK packet has been received by this side. */ > > > + uint32_t last_ack_seen:1; > > > + /**< If set, indicates that there is unacked data of the > > connection. */ > > > + uint32_t data_unacked:1; > > > + /**< Maximal value of sequence + payload length over sent > > > + * packets (next ACK from the opposite direction). > > > + */ > > > + uint32_t sent_end; > > > + /**< Maximal value of (ACK + window size) over received packet > > + > > > length > > > + * over sent packet (maximal sequence could be sent). > > > + */ > > > + uint32_t reply_end; > > > > This comment is for all members that are part of the packet, Do you > > think it should be in network order? > > Almost none of the fields are part of the packet. Indeed, most of them are calculated from the packets information. So I prefer to keep the host order easy for using and > keep all the fields of the whole structure the same endianness format. > What do you think? Can you mention it in the documentation and comments? That all the values are in host byte order and need to be converted to network byte order if the HW needs it that way --000000000000c3e4eb05c01ded95--