From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4951AA0524; Sat, 4 Jul 2020 16:36:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1B3531DBA7; Sat, 4 Jul 2020 16:36:08 +0200 (CEST) Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by dpdk.org (Postfix) with ESMTP id 879741DB9C for ; Sat, 4 Jul 2020 16:36:06 +0200 (CEST) Received: by mail-oi1-f196.google.com with SMTP id x83so21182307oif.10 for ; Sat, 04 Jul 2020 07:36:06 -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=J4kstVyyWG5wnJSuM5xSiwEFBbqovcN7iuz1mTbIZqA=; b=bxLjT7cRpu0OJdqB9zKNRs1iwm9go3Na4//U8/Y2Dk2/1QOOk+Kfd9D5xY+9sb5b4k Mhdxwfz48KS9Kp1ArlGYuMBOMS5ujG1H+ldnrS8ImUuKkZQxxv+InnjadSxTsDfjYrbN j0KcyHc+dxVdMna0VoNGAntrAhDKAzgXg/i4U= 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=J4kstVyyWG5wnJSuM5xSiwEFBbqovcN7iuz1mTbIZqA=; b=igeE6A5ASWHUJFkc/cypRZ7FwWysVtwz1BLB1icgH3LhBtEEFPVnoByRn1i/aw+qIz /d6iDH7gNldLReEoI8ABVfluYjgxZD5A/4BVV21tsDPytb50JYHGNGpINm3Y2DSphqHL sP55iWPICOtE06JWtrG9AiXwar8+XSM2pceVynsm4V6Fs2++eLTEdYBOxznW49HDIEtX QHx+jKc3jJCLLnvpo+HL7DX45rKSR7yntHboD/KddlbhIlcy0N/kZM6OtZC0NxIdxAFg 39MgwrXRb8+VOED0vID37swDPKIKTXRNv/KlW/IQLB7qvnjepJHed5AEZ+IRdq/Iay2+ K9yA== X-Gm-Message-State: AOAM532tEtT+D0YRzvlLNNnmjcURSjTP+y5kmACxghMPmWeIEcSaVOWn J5IH1OPjd/uLZjNysyyDsDqSUfYyLpGQCjsrNwBvJA== X-Google-Smtp-Source: ABdhPJzjCxnycKpvo7zOGmF3/qVEIUZhekO7sxDjCWKi8XLrsFaGjziaIapMTiD7R2q/FEbop6HyBO/9fmlOmNvnEA0= X-Received: by 2002:a05:6808:6ca:: with SMTP id m10mr31596272oih.27.1593873364334; Sat, 04 Jul 2020 07:36:04 -0700 (PDT) MIME-Version: 1.0 References: <1593102379-400132-1-git-send-email-jiaweiw@mellanox.com> <2018114.U5Vea0xDAA@thomas> In-Reply-To: <2018114.U5Vea0xDAA@thomas> From: Ajit Khaparde Date: Sat, 4 Jul 2020 07:35:48 -0700 Message-ID: To: Thomas Monjalon Cc: Matan Azrad , Jerin Jacob , "Jiawei(Jonny) Wang" , Ori Kam , Slava Ovsiienko , dpdk-dev , Raslan Darawsheh , "ian.stokes@intel.com" , "fbl@redhat.com" , Ferruh Yigit , Andrew Rybchenko Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2 1/7] ethdev: introduce sample action for rte flow X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 Fri, Jul 3, 2020 at 8:27 AM Thomas Monjalon wrote: > 03/07/2020 17:08, Jerin Jacob: > > On Fri, Jul 3, 2020 at 8:25 PM Matan Azrad wrote: > > > From: Jerin Jacob: > > > > When adding overlapping API(rte_eth_mirror_rule_set()) in the same > > > > library(ethdev). > > > > Please depreciate the old API. > > > > We should not have two separate paths for the same function in the > same > > > > ethdev library. It is pain for app and driver developers. > > > > > > What are about all the other rte_flow parallel configuration APIs in > ethdev: > > > promiscuous_enable; > > > promiscuous_disable; > > > allmulticast_enable; > > > allmulticast_disable; > > > mac_addr_remove; > > > mac_addr_add; > > > mac_addr_set; > > > set_mc_addr_list; > > > vlan_filter_set; > > > vlan_tpid_set; > > > vlan_strip_queue_set; > > > vlan_offload_set; > > > vlan_pvid_set; > > > udp_tunnel_port_add; > > > udp_tunnel_port_del; > > > ... > > > > > > These APIs can be replaced easily by rte_flow API. > > > Do you think we need to deprecate all? > > > > I think, basic stuff like below can have separate API. > > 1) promiscuous_enable; > > 2) promiscuous_disable; > > 3) allmulticast_enable; > > 4) allmulticast_disable; > > 5) mac_addr_remove; > > 6) mac_addr_add; > > 7) mac_addr_set; > > 8) set_mc_addr_list; > > "Basic" is not a precise definition :) > I would say port-level configuration should remain > out of rte_flow API. > +1 > > > But The VLAN and UDP related should be rte_flow candidates.(IMO) > I do not have a strong opinion on VLAN in port-level or rte_flow list. But isn't the UDP port number for tunnels a port-level setting for HW? > > Yes definitely, tunneling is better managed with rte_flow. > > This is an important discussion, I Cc other ethdev maintainers. > Note: this is an ethdev patch, all ethdev maintainers should be Cc'ed. > Aren't you using --cc-cmd devtools/get-maintainer.sh ? > > >