DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	Hyong Youb Kim <hyonkim@cisco.com>
Cc: "John Daley (johndale)" <johndale@cisco.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	Qi Zhang <qi.z.zhang@intel.com>, "dev@dpdk.org" <dev@dpdk.org>,
	Shahaf Shuler <shahafs@mellanox.com>,
	Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	David Marchand <david.marchand@6wind.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Stephen Hemminger <stephen@networkplumber.org>,
	gaetan.rivet@6wind.com
Subject: Re: [dpdk-dev] [PATCH v2] net/enic: add private API to set ingress VLAN rewrite mode
Date: Tue, 19 Mar 2019 17:29:16 +0000	[thread overview]
Message-ID: <378fbf05-d8c5-8a25-a1e6-8e21e3083ae3@intel.com> (raw)
Message-ID: <20190319172916.nzDN1gW_ryyC7IWG83oWC49ScNxNr_l83Q379pUnBwU@z> (raw)
In-Reply-To: <50100234.Q8zoU6jCWW@xps>

On 3/14/2019 10:04 PM, Thomas Monjalon wrote:
> 14/03/2019 03:58, Hyong Youb Kim:
>> On Wed, Mar 13, 2019 at 10:29:53PM +0100, Thomas Monjalon wrote:
>>> 13/03/2019 22:11, John Daley (johndale):
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 13/03/2019 19:32, Ferruh Yigit:
>>>>>> On 3/5/2019 7:11 AM, Hyong Youb Kim wrote:
>>>>>>> The driver currently has a devarg to set the rewrite mode during
>>>>>>> init. Some apps want to programatically set it after running
>>>>>>> rte_eal_init() and finding that ports are VIC. Add a private
>>>>>>> function to support such applications.
>>>>>>
>>>>>> It is not good idea to have PMD specific APIs (although we already have
>>>>> some).
>>>>>>
>>>>>> Specific to this case, as far as I can see it is to pass a config
>>>>>> value and do the action related to it, what would you think having a
>>>>>> generic key/value set/get API in ethdev for this? Similar to rawdev
>>>>> get_attr/set_attr [1]?
>>>>>>
>>>>>> My concern is it may turn into something like ioctl with many things
>>>>>> pushed to it, and cause possible duplication ...
>>>>>
>>>>> Yes, it is clearly ioctl style.
>>>>>
>>>>> Please could you explain more what is the rewrite mode?
>>>>> Does it apply to the port or the queue?
>>>>>
>>>> It applies to a port. By default the Cisco VIC VLAN tags every packet on ingress even if they were untagged coming in on the wire. They are tagged with VLAN 0 or a VLAN id programmed into the NIC depending on the configuration. Its part of the original design, to maintain priority bits, ancient history.
>>>>
>>>> Some apps don't like this (VPP) or take a slower path (OVS). Hyong added a ig-vlan-rewrite=untag devarg to disable this (leave untagged/default vlan packets untagged) during rte_eal_init and this is helpful for OVS, but VPP likes to set the rewrite mode after rte_eal_init() and finding the ports are VIC ports. So that is the reasoning behind the private API call.
>>>
>>> It looks like an application will always set this flag or never.
>>> So I don't see the need for an API function.
>>> Why VPP prefers set this flag later?
>>> Would it be better to have some driver-specific flags, no matter the ports?
>>
>> As is, there seem to be two ways apps deal with NIC-specific tweaks/quirks.
>>
>> 1. Leave everything to the user.
>>
>> Let the human user specify NIC-specific settings (e.g. devarg,
>> not-so-standard MTU/MRU, offloads with not-so-uniform behavior). The
>> app simply passes these to DPDK and does nothing else. Devargs are
>> passed to rte_eal_init. Other settings are applied during the
>> configure phase after rte_eal_init.
>>
>> For example, OVS seems to go for a smallest common denominator that
>> works with most NICs out of the box. Otherwiese, it kinda falls into
>> this camp.
>>
>> For a problematic NIC that needs user intervention, troubleshooting
>> goes like this :-)
>> - Install app.
>> - Run with settings that worked on a previous machine.
>> - Some features suddenly do not work.
>> - Google search this and that ("why this does not work on this server?").
>> - Contact vendors.
>> - Find out this NIC has unexpected behavior.
>> - Set devarg, tweak MTU/MRU, ... ("Oh need to set this for ..").
>> - Now the features work.
>>
>> 2. Hide ugly tweaks from the user.
>>
>> VPP falls into this camp. The user specifies BDFs in the config (no
>> devargs). The app calls rte_eal_init(BDFs), iterates through the
>> discovered ports, applies whatever NIC-specific settings necessary
>> during the configure phase (i.e. do this for vendor A NIC, do that for
>> vendor B NIC), and then start the ports.
>>
>> The ingress vlan rewrite mode is devarg now, so is not usable in this
>> model. One way around it is a private API. Driver specific flags
>> during the configure phase would also work fine. Though, enic might be
>> the only user of those flags.
> 
> I think DPDK needs some driver configuration.
> Currently the config is done per device with devargs.
> The next devargs format allow this:
> 	driver=enic,rewrite=on
> and it can be passed to rte_eal_init().
> 
> We did not progress on the implementation of this format in recent months,
> but you are welcome to help!
> Instead of passing devargs in the whitelist/blacklist options,
> we should introduce a new option, like --dev.

But it will be still devarg in new implementation.
I guess for this use case, there is a need to pass this information from an API.
Options can be:
1- PMD specific API
2- Extend ethdev dev_ops for each usecase
3- Have a generic API, as suggested above
4- Extend configure to accept flags

I don't see a winner in above list, each has some problems. Any comment on how
to proceed?

  parent reply	other threads:[~2019-03-19 17:30 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05  5:56 [dpdk-dev] [PATCH] " Hyong Youb Kim
2019-03-05  7:11 ` [dpdk-dev] [PATCH v2] " Hyong Youb Kim
2019-03-13 18:32   ` Ferruh Yigit
2019-03-13 20:36     ` Thomas Monjalon
2019-03-13 20:36       ` Thomas Monjalon
2019-03-13 21:11       ` John Daley (johndale)
2019-03-13 21:11         ` John Daley (johndale)
2019-03-13 21:29         ` Thomas Monjalon
2019-03-13 21:29           ` Thomas Monjalon
2019-03-14  2:58           ` Hyong Youb Kim
2019-03-14  2:58             ` Hyong Youb Kim
2019-03-14 22:04             ` Thomas Monjalon
2019-03-14 22:04               ` Thomas Monjalon
2019-03-19 17:29               ` Ferruh Yigit [this message]
2019-03-19 17:29                 ` Ferruh Yigit
2019-03-19 17:36                 ` Thomas Monjalon
2019-03-19 17:36                   ` Thomas Monjalon
2019-03-19 18:00                   ` Ferruh Yigit
2019-03-19 18:00                     ` Ferruh Yigit
2019-03-19 20:30                     ` Thomas Monjalon
2019-03-19 20:30                       ` Thomas Monjalon
2019-03-20 10:45                       ` Ferruh Yigit
2019-03-20 10:45                         ` Ferruh Yigit
2019-03-20 11:46                         ` Thomas Monjalon
2019-03-20 11:46                           ` Thomas Monjalon
2019-03-25 11:49                           ` Ferruh Yigit
2019-03-25 11:49                             ` Ferruh Yigit
2019-03-25 13:26                             ` Gaëtan Rivet
2019-03-25 13:26                               ` Gaëtan Rivet
2019-03-25 13:33                               ` Gaëtan Rivet
2019-03-25 13:33                                 ` Gaëtan Rivet
2019-03-26  6:39                                 ` Hyong Youb Kim
2019-03-26  6:39                                   ` Hyong Youb Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=378fbf05-d8c5-8a25-a1e6-8e21e3083ae3@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=arybchenko@solarflare.com \
    --cc=david.marchand@6wind.com \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=hyonkim@cisco.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=johndale@cisco.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=qi.z.zhang@intel.com \
    --cc=shahafs@mellanox.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).