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 E2F5F4545B; Fri, 14 Jun 2024 23:24:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BFB6D41133; Fri, 14 Jun 2024 23:24:47 +0200 (CEST) Received: from mail-oo1-f46.google.com (mail-oo1-f46.google.com [209.85.161.46]) by mails.dpdk.org (Postfix) with ESMTP id CB7A44060B for ; Fri, 14 Jun 2024 23:24:46 +0200 (CEST) Received: by mail-oo1-f46.google.com with SMTP id 006d021491bc7-5b9706c84e5so1407504eaf.1 for ; Fri, 14 Jun 2024 14:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1718400286; x=1719005086; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pgmpbGBZpzd5FPI2HESDqzJd0A4faxer33QSlskulK4=; b=cbXGSMAIopEMesZ91ZPUNRAceFtxBii2Mumej1IqqcZ4cWHWHFgmFU4QHjH43oeahy AqCBAWykVYo/jPb8vgLTUUla7Qa1U/EtkweWJwKi1M258m2KAD4Xjy1ATbb588uHqzOe aljQ9/sBopxMbNPyEmlvnttYT65O3g+aDyYHg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718400286; x=1719005086; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pgmpbGBZpzd5FPI2HESDqzJd0A4faxer33QSlskulK4=; b=k3M1qHedlleiNZUcJgX1t+/g6DnX6Cyog1Fyx9zzj8n8eYAcJeYogcGlSWLZWBKDvo +R/EUovrWQOL0sm1/KEwrafKpNyKYDwKgt9ns5ECBmMurW9H1okmjOr8416ile0qqSQX DihWSaFTJdCnlZ0KbE/EADM1Bjw7npICpE/D8CWaVInc7QTlsstQ9y4eMvCQll4ERkmL ReO/l0pTCVi6snbIP3XZCoOgyHqNyyHRs3S0vIgyufiPJ15dHro/tvG0Ts39P+o9tcgM la2eZKSliOErlAUmZVK6C6O03XiE3DPIFY67ntmMpo93H4jNP7+thbAWnVnGuL9aSdDB VydQ== X-Forwarded-Encrypted: i=1; AJvYcCUX5GWLXjZi7lW+0uLBLSKc4WvQ1zarAcFwNMo8QrE2+1J7AAO3bMV6hj0Sc+n0qTmpBoS3EvPF2FGtFdE= X-Gm-Message-State: AOJu0Yw0EQwV7gV5XjE6duqHPblTldfvRLfJ6zWR2PZ6Cv9zGyqcvFTI NZgcXPDbDbyBJfLX+xNXzw/iS7BL2hYffv8Jl+V00F08lxAYdbnjl+pqY8LIzZSG1V08rRiZ2X4 w6iVj7EiPLskoJFCyTT86m59S2mKlQjwSmrGipQ== X-Google-Smtp-Source: AGHT+IE830cG4Ixyt/0e9uG9FlyCEaPhO/vTSjpUKE+HddL4OQVQyHYaDdRc1JW3fHWXOLgimdFWR4YDaIDAdbIWJFw= X-Received: by 2002:a05:6820:808:b0:5ba:cb03:2a13 with SMTP id 006d021491bc7-5bdad9f8897mr4517692eaf.0.1718400286044; Fri, 14 Jun 2024 14:24:46 -0700 (PDT) MIME-Version: 1.0 References: <20240611161606.23881-2-dmarx@iol.unh.edu> <20240614150238.26374-1-dmarx@iol.unh.edu> <20240614150238.26374-2-dmarx@iol.unh.edu> In-Reply-To: From: Patrick Robb Date: Fri, 14 Jun 2024 17:24:35 -0400 Message-ID: Subject: Re: [PATCH v3 1/3] Added VLAN commands to testpmd_shell class To: Jeremy Spewock Cc: Dean Marx , Honnappa.Nagarahalli@arm.com, juraj.linkes@pantheon.tech, paul.szczepanek@arm.com, yoan.picchi@foss.arm.com, bruce.richardson@intel.com, luca.vizzarro@arm.com, dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Fri, Jun 14, 2024 at 4:29=E2=80=AFPM Jeremy Spewock wrote: > > I wonder whether, when convenient, we want to name the methods more or > > less 1:1 according to the actual testpmd text command they send? I.e. > > in this case should the method be named vlan_set_filter_on instead of > > vlan_filter_set_on (aligns better with "vlan set filter on {port}")? > > The intellisense provided by the testpmd methods is indeed a QoL > > improvement for folks writing testsuites, but at the same time people > > who use testpmd will always have the real commands ingrained in their > > thoughts, so if we try to stay as true to those as possible, we get > > the stability and intellisense and also the method names are still > > intuitive. > > I generally try to name these methods in a more human-readable way, so > my intuition would lean more towards naming it something like > `set_vlan_filter_on` or `set_vlan_strip_on`. I could see how it might > make it easier for some testpmd developers, so I'm not sure which > would be better. Personally, as someone who is less familiar with all > the ins and outs of testpmd, I prefer the human-readable approach. I think this is compelling, but to play devil's advocate, I also think it's not just testpmd developers who might care. The broad community of DPDK developers, who are working on DPDK features and might want to write DTS testsuites in the future, are probably also already pretty familiar with testpmd params. If they start using the framework, it may be a benefit for the method names to be intuitive, so they don't have to in essence relearn how to use testpmd just to write testsuites for DTS. Probably not a big deal given as you say the human readable approach is pretty intuitive too... anyways maybe this can be a discussion point at the DTS meeting next week. I guess people can always fall back on testpmd.send_command() if they don't like the human readable methods...? Or would we want to ban that? https://doc.dpdk.org/guides/testpmd_app_ug/testpmd_funcs.html Should testpmd class have a method for each runtime command? It's a long list. Or just methods for the most common commands? Well, we'll chat at the DTS meeting. > > > > > Maybe even think tiny things like renaming the method set_forward_mode > > to set_fwd_mode to align 1:1 with testpmd is good. > > > > That's just my perspective though - I would be interested to see > > whether others feel the same or not. > > > > > > 2.44.0 > > >