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 A71CFA0547; Wed, 29 Sep 2021 19:44:43 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C995410EB; Wed, 29 Sep 2021 19:44:43 +0200 (CEST) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by mails.dpdk.org (Postfix) with ESMTP id 1E67D410EA for ; Wed, 29 Sep 2021 19:44:41 +0200 (CEST) Received: by mail-pf1-f169.google.com with SMTP id s55so1530095pfw.4 for ; Wed, 29 Sep 2021 10:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=ko0T9LBtumiy0IOjW8vSdy/i/O57ggjG9SJQhMBPFL8=; b=PCALhpriSnYj2zOOUVajPvWCSZmeYJkdq45mCZC8LeVsC3LnNv67i6s6vWlU2IX62T sXNxc+1+ZXFn2u9lWzzGRenvZ+aNF2AZXpcL4KOT5p5hZnXD4poozB0e/JYubwojuZ+U LT4FmrkO38Pa7qsEJLsEy1JW9GxLLRInB0iSnMM2By+18LWGzCqSxe/cSVwJpekD3Rg/ GmcOka8otW1tDByvWAy6/O+3q+Li2cGIH78HEB1WvzjFV2NicNisAtEUcUDNNFcgIngt eu7FyoroFo4kbDYVDA7/us+4e0+is+njKoG/0lmmRxSbPMejTGW2iBf80NacR88MuFxb UOxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=ko0T9LBtumiy0IOjW8vSdy/i/O57ggjG9SJQhMBPFL8=; b=astM70dn8A+YHs/NnseXM4wmWi/vE8feUnhE+W3sDEp8Z4sSnGx5OWZYE7B4xIzMkA w+gpZYAk6jreNt51G606OrH60C9bSiPwgbDisokiHwjY0zb9rFyO/BCqahGQVhrWynIX dEBpPOhH9kqMbhHKaFL3rttGckQEmHqKYOsk1XDcb6g10wI3jDNOTsh5oqlGhTNXVlWv JYlk2xoOEnNa7wpznfR+531Jms6U4+NHHD5L/fEk69AuBtY6gqi1ZnJR3N55/VtPgzRO NQDfDxtkUhH6UHUwiJFqLnftLzkyYsC+mKSeNX6brQVS9bcLEyJQq5HpdxaNaDg+3XJQ hBIg== X-Gm-Message-State: AOAM533DEe1rBD88ksSkE0xX9gcr6foa9sDg+zMobwHr8SBiHrNSJ05d 32j5BPvdnNlb14U9E0AQ4dabYhCCJiTJCg== X-Google-Smtp-Source: ABdhPJzeVHdVCdt5gUdcRkbMvWxPotXupuZl+l3VANpLqAJoABPMVzHbNl2jofe1RBBumgKPx2Oxug== X-Received: by 2002:a05:6a00:9c:b0:448:603f:720b with SMTP id c28-20020a056a00009c00b00448603f720bmr997478pfj.66.1632937480128; Wed, 29 Sep 2021 10:44:40 -0700 (PDT) Received: from hermes.local (204-195-33-123.wavecable.com. [204.195.33.123]) by smtp.gmail.com with ESMTPSA id c8sm316707pjr.38.2021.09.29.10.44.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 10:44:39 -0700 (PDT) Date: Wed, 29 Sep 2021 10:44:36 -0700 From: Stephen Hemminger To: Thomas Monjalon , Ori Kam Cc: dev@dpdk.org Message-ID: <20210929104436.6fd88409@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [dpdk-dev] Querying for rte_flow support? 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" Have a problem with auto-detecting whether device driver supports rte_flow. Ideally in application would like to be able adapt to handle devices that do rte_flow and those that do not. If device does not support rte_flow, then configure with RSS across multiple cores; if device does support rte_flow then assign traffic to queue based on match (on MAC). The problem is that there really is not a good API in DPDK for checking. Most device drivers will not give the correct return to rte_flow_validate unless the device is configured already, and some require device to be started. In order to configure, the application has to choose how many queues to use and that is the reason it wants to know if rte_flow will work! The other alternative is looking at DPDK internal data structs to see if device supports flow operations. That is not good, and causes more issues in later releases. Looks like rte_flow has a "chicken/egg problem" here.