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 5C4AFA04BA; Mon, 11 Nov 2019 06:02:52 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9A5732956; Mon, 11 Nov 2019 06:02:51 +0100 (CET) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id 16464235 for ; Mon, 11 Nov 2019 06:02:50 +0100 (CET) Received: by mail-il1-f196.google.com with SMTP id d83so10927982ilk.7 for ; Sun, 10 Nov 2019 21:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=S8e70dcEZRKKrejNNk9drxjyy9LIg4x7nxeFijLm0yc=; b=rb0EsSNDOGBuHqpKfNBGRn5zBB+TvDSUFHL1isO19touJ9dYH7/cmOcS9wirV+7tGw 5q0Pi5k4qubPm1nVQ8CXiyeUt+lx4fW98irv0YyYsOrds+DSr+aGBHUlzjSXAEqVHcbv lFd6rc+Ox1RR+TaToREUz6COAx9g78bOt88uxf9JYsVeZfxjfwywrRhZ82HL6946Micv JG3/RP0sj18XkERVD6Cvzk9ikEiLqAeknopifF5RxOxdGwiP1drorDQKBljKqQzh8HAh sOi7zdQIYrpoRTplG1RdQ9IKJSkpqHdkG0AzyhkBPXhQbCEMFwqTepLcP2G2qqJT+5gf djMQ== 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:content-transfer-encoding; bh=S8e70dcEZRKKrejNNk9drxjyy9LIg4x7nxeFijLm0yc=; b=qo8YNqed/45Bpyj1nPAEO5KWfjZDPHsuXJgG3I/Wz+VEMtzyn7D0VZtItbj48fS4NN SVEGz/qXtFS3I2xXuVymYJCjdTPOIiUaHj3sTwxHZXgx42gB5OA3a95If1bSKo8vp/A4 qpeasmdkWG4gysKrxHBOW+f4dvZaf8OfiOOT/t78VsVP1xK2tNuTw4y5zFs8AjsQ9r9i rBmtRXbQ97F/TQYU84AdU+wS09aNJ7mjfhc+falt3HrlWax58ae7U5LA1Karkzf9R1jW QI4UxwJzA1LNRwDEZjuvjHzAq6plG3F13UxAGbRjwdHdQQ2TEWUDwv2X8EeKMNd26bF6 aaSw== X-Gm-Message-State: APjAAAUQp8igOa0CEXJ19gcdq7aiM1Pwo2buJ9K4zftiZ6AI7BqZgva8 H4Rr9rheXG74ZSmvn7QxMCO9072CuT423rZUYnw= X-Google-Smtp-Source: APXvYqxkSr/37t1tyn1y6FhEGZwzjK4ozPa8MU6Gs8oTtLk8+WsOQSko7uc10NcPOe9bJFXPW9sny7CJr+Hss8JKwvI= X-Received: by 2002:a92:4b07:: with SMTP id m7mr27976337ilg.271.1573448569142; Sun, 10 Nov 2019 21:02:49 -0800 (PST) MIME-Version: 1.0 References: <20191029153722.4547-1-pbhagavatula@marvell.com> <20191106191803.15098-1-pbhagavatula@marvell.com> <20191106191803.15098-9-pbhagavatula@marvell.com> <2601191342CEEE43887BDE71AB97725801A8C83195@IRSMSX104.ger.corp.intel.com> In-Reply-To: From: Jerin Jacob Date: Mon, 11 Nov 2019 10:32:32 +0530 Message-ID: To: Pavan Nikhilesh Bhagavatula Cc: "Ananyev, Konstantin" , "Yigit, Ferruh" , Andrew Rybchenko , Jerin Jacob Kollanukkaran , "thomas@monjalon.net" , "Lu, Wenzhuo" , "Wu, Jingjing" , "Iremonger, Bernard" , "Mcnamara, John" , "Kovacevic, Marko" , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v16 8/8] app/testpmd: add command to set supported ptype mask 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 Mon, Nov 11, 2019 at 10:26 AM Pavan Nikhilesh Bhagavatula wrote: > > >On Fri, Nov 8, 2019 at 7:24 PM Ananyev, Konstantin > > wrote: > >> > >> > >> > >> > -----Original Message----- > >> > From: dev On Behalf Of Ferruh Yigit > >> > Sent: Thursday, November 7, 2019 7:41 PM > >> > To: Jerin Jacob > >> > Cc: Pavan Nikhilesh ; Andrew > >Rybchenko ; jerinj@marvell.com; > >> > thomas@monjalon.net; Lu, Wenzhuo ; > >Wu, Jingjing ; Iremonger, Bernard > >> > ; Mcnamara, John > >; Kovacevic, Marko > >; > >> > dev@dpdk.org > >> > Subject: Re: [dpdk-dev] [PATCH v16 8/8] app/testpmd: add > >command to set supported ptype mask > >> > > >> > On 11/7/2019 6:55 PM, Jerin Jacob wrote: > >> > > > >> > > > >> > > On Fri, 8 Nov, 2019, 12:10 am Ferruh Yigit, >> > > > wrote: > >> > > > >> > > On 11/6/2019 7:18 PM, pbhagavatula@marvell.com > >> > > wrote: > >> > > > From: Pavan Nikhilesh >> > > > > >> > > > > >> > > > Add command to set supported ptype mask. > >> > > > Usage: > >> > > > set port ptype_mask > /* *************** > >> > > > > >> > > > /* list of instructions */ > >> > > > @@ -19155,6 +19237,7 @@ cmdline_parse_ctx_t main_ctx[] =3D > >{ > >> > > > (cmdline_parse_inst_t *)&cmd_show_vf_stats, > >> > > > (cmdline_parse_inst_t *)&cmd_clear_vf_stats, > >> > > > (cmdline_parse_inst_t > >*)&cmd_show_port_supported_ptypes, > >> > > > + (cmdline_parse_inst_t *)&cmd_set_port_ptypes, > >> > > > (cmdline_parse_inst_t *)&cmd_ptype_mapping_get, > >> > > > (cmdline_parse_inst_t *)&cmd_ptype_mapping_replace, > >> > > > (cmdline_parse_inst_t *)&cmd_ptype_mapping_reset, > >> > > > diff --git a/app/test-pmd/testpmd.c b/app/test- > >pmd/testpmd.c > >> > > > index 5ba974162..812aebf35 100644 > >> > > > --- a/app/test-pmd/testpmd.c > >> > > > +++ b/app/test-pmd/testpmd.c > >> > > > @@ -2024,6 +2024,7 @@ start_port(portid_t pid) > >> > > > queueid_t qi; > >> > > > struct rte_port *port; > >> > > > struct rte_ether_addr mac_addr; > >> > > > + static uint8_t clr_ptypes =3D 1; > >> > > > > >> > > > if (port_id_is_invalid(pid, ENABLED_WARN)) > >> > > > return 0; > >> > > > @@ -2153,6 +2154,10 @@ start_port(portid_t pid) > >> > > > } > >> > > > } > >> > > > configure_rxtx_dump_callbacks(verbose_level); > >> > > > + if (clr_ptypes) { > >> > > > + clr_ptypes =3D 0; > >> > > > + rte_eth_dev_set_ptypes(pi, > >RTE_PTYPE_UNKNOWN, NULL, 0); > >> > > > + } > >> > > > >> > > I am not sure about this command, we have now capability to > >set/disable ptypes > >> > > on demand, why disabling them by default? > >> > > > >> > > > >> > > As forward engines are not using the ptype offload. If a specific > >forwa > >> > > need the offload, it can be enabled. > >> > >> Well, at least now user can see ptype in pkt dump with 'set verbose > > >0' > >> It's definitely looks loke a a behavior change. > >> Wonder why it can't be done visa-versa? > >> Keep current behavior as default one (all ptypes are un-masked) and > >> have special command to disable/enable ptypes. > >> as I understand such command was added by these series. correct? > > > >IMO, we are following the principle that by default all offloads are > >disabled and enable it > >based on the need to have optimal performance across the DPDK. This > >change will be > >on the same theme. > > > >Regarding the verbose > 0 cases, I think, we can call > >rte_eth_dev_set_ptypes() to all PTYPES on > >the setting verbose callback. > > Agree verbose > 0 case we can do set_ptypes with > RTE_PTYPE_ALL_MASK. But what if the user wants to verify > rte_eth_dev_set_ptypes() call itself in verbose mode?. > Example: > > set port 0 ptype_mask RTE_PTYPE_L3_MASK > set verbose 1 > > In this case user expects to see only L3 mask set. Wouldn=E2=80=99t it be= confusing if > we set RTE_PTYPE_ALL_MASK under the hood when verbose level is increased? I thought of adding RTE_PTYPE_ALL_MASK in the callback to maintain the existing behavior if there is any concern in that area. Either way is fine with me. (implicit RTE_PTYPE_ALL_MASK in a callback or explicit mask set in command line)