From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=BAYES_00,DKIM_ADSP_DISCARD, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59719C07E9C for ; Tue, 6 Jul 2021 08:04:57 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 4FAD061945 for ; Tue, 6 Jul 2021 08:04:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4FAD061945 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=oktetlabs.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7DB6640688; Tue, 6 Jul 2021 10:04:55 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id A8E7C4067E for ; Tue, 6 Jul 2021 10:04:54 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 206FD7F4FE; Tue, 6 Jul 2021 11:04:54 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 206FD7F4FE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1625558694; bh=s0z4C5k1tTdyl/lU5r+WnRwbB8F7Clhk3l1HQDnSCKA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=wlOghYtkPYQOZLHwPhj6SqTedU7AABzsQw5cWkNmC9uCrk6JhBHynEBoBcRkXSoz4 OFjqVyYDxJFuBs7/DtyZeSa9uu+/a+5hPg/ql3Sx40IAfWZpz/l3/+g5bomPmaC+rT ZyDH/TmbSFeRoAA+SAWhugpQnj8MkFfU5rhrnUhc= To: "Zhang, Qi Z" , "Zhang, AlvinX" , "ajit.khaparde@broadcom.com" Cc: "dev@dpdk.org" References: <20210603080352.10924-1-alvinx.zhang@intel.com> <20210615081956.23656-1-alvinx.zhang@intel.com> <7930ac91-7f55-6b42-f086-701d952fc151@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <774225cd-b2f9-30e2-31c3-651329dfa25e@oktetlabs.ru> Date: Tue, 6 Jul 2021 11:04:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3] ethdev: add IPv4 and L4 checksum RSS offload types 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" On 7/6/21 10:18 AM, Zhang, Qi Z wrote: > > >> -----Original Message----- >> From: Zhang, AlvinX >> Sent: Tuesday, July 6, 2021 3:06 PM >> To: Andrew Rybchenko ; Zhang, Qi Z >> ; ajit.khaparde@broadcom.com >> Cc: dev@dpdk.org >> Subject: RE: [PATCH v3] ethdev: add IPv4 and L4 checksum RSS offload types >> >>>> @@ -537,6 +537,8 @@ struct rte_eth_rss_conf { >>>> #define ETH_RSS_PPPOE (1ULL << 31) >>>> #define ETH_RSS_ECPRI (1ULL << 32) >>>> #define ETH_RSS_MPLS (1ULL << 33) >>>> +#define ETH_RSS_IPV4_CHKSUM (1ULL << 34) >>>> +#define ETH_RSS_L4_CHKSUM (1ULL << 35) >>> >>> What does efine which L4 protocols are supported? How user will know? >> >> I think if we want to support L4 checksum RSS by using below command port >> config all rss (all|default|eth|vlan|...) >> >> We must define TCP/UDP/SCTP checksum RSS separately: >> #define ETH_RSS_TCP_CHKSUM (1ULL << 35) >> #define ETH_RSS_UDP_CHKSUM (1ULL << 36) >> #deifne ETH_RSS_SCTP_CHKSUM (1ULL << 37) >> >> Here 3 bits are occupied, this is not good for there are not many bits available. >> >> If we only want to using it in flows, we only need to define >> ETH_RSS_L4_CHKSUM, because the flow pattern pointed out the L4 protocol >> type. >> flow create 0 ingress pattern eth / ipv4 / tcp / end actions rss types l4-chksum >> end queues end / end > > +1, the pattern already give the hint to avoid the ambiguity and I think we already have ETH_RSS_LEVEL to figure out inner or outer. The problem that it may be used in generic RSS flags which has no the context. Also even in the case of flow API context could have no L4 protocol at all. Is UDP checksum 0 treated as no checksum and go to default queue or treated as a regular checksum with value equal to 0? I tend to agree that 3 flags is too much for the feature, but one flag without properly defined meaning is not good as well. I just want rules to be defined and documented.