From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 9BE918D96 for ; Mon, 18 Jan 2016 16:50:35 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id r129so56637608wmr.0 for ; Mon, 18 Jan 2016 07:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=vCY4pK+evMXsWkN3Q69DAEgD0YfAk1tX040I8cb8Ufk=; b=wBAaTLNdCBK9Ur17BAZYkoQZcO0IimdkgWOKg5cDSkgA0Qi+1nOmQOkUkQqLE9AwFo PGzPjr/AQXqRx2rj+vyhN1Iq2TCgfjg5kqdXotA7HVpYNdnZ1wLQnC7Bu7uWJrshd6Ie XFogobczDyp2V+ZVYCxSeaUTyTDKRzqF6+I1HZePiPGSbJQesNZFkcAw6XAhAzwdotsm OCduep9pLP7t0WfxoHzALk2d7Jw1czHbVHuYUNq5RrfNtml+8nVMdDyRiy+Tyyh+qpZw 8qGAQg+j+sFoUokwLDY1sLza/hIOIgrEqQCOKaEL6yp0EMuZY4n3JdsUhZ//y9bpMNYA CElA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=vCY4pK+evMXsWkN3Q69DAEgD0YfAk1tX040I8cb8Ufk=; b=W5WYDHDeqSXKqKWRk9ypolEUrzXqYopTWPgKZLebo5kqH23SKBm3yOCf+1JMOBl8KP mB2EUtG+uEiFdncVWCICcyHDD2WVd9U39MIOELyVdtJts3o08+68zVj/BcyiIXHzY708 spUf76l0M8+AhPhxklyIOEYNUA25aslo3CMaxTfxbZqTR6G1J+CelmI8o8MIxv/hcIOO 8Mcf98e2m2QAwWXRA2+JQogK/BGAC3TO1BdpuExSHZR989l5VDH9UZm+k9nzENUllmsP IWtDJGbUXVSsdqt/AA9nrkxDblRYesx13B5V+7dDm6YOQqyj8tmbnnvPppR29DLnUrbA r+7w== X-Gm-Message-State: ALoCoQkzvhjUkjK7iGiR4YVpR8CvvDisjL0HQXpbxZQ+O91M3ttVipE8XM6AEAeu1si9bpJbg7BnFCwAZUgglR3sBQKXVWJaug== X-Received: by 10.194.103.234 with SMTP id fz10mr25112143wjb.31.1453132235403; Mon, 18 Jan 2016 07:50:35 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id i196sm16290525wmf.23.2016.01.18.07.50.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 07:50:34 -0800 (PST) From: Thomas Monjalon To: David Marchand Date: Mon, 18 Jan 2016 16:49:34 +0100 Message-ID: <3031367.ptgEOhAmUa@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <20160114124652.1a02931e@pcviktorin.fit.vutbr.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org, Jan Viktorin Subject: Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:50:35 -0000 2016-01-16 16:53, David Marchand: > On Thu, Jan 14, 2016 at 12:46 PM, Jan Viktorin wrote: > > On Thu, 14 Jan 2016 11:38:16 +0100 > > David Marchand wrote: > >> Here is a proposal of a big cleanup in ethdev (cryptodev would have to > >> follow) and eal structures. [...] > >> ABI is most likely broken with this, but I think this discussion can come later. > > > > I was trying in my initial approach to stay as much API and ABI backwards > > compatible as possible to be acceptable into upstream. As just a few > > people have shown their interest in these changes, I consider the ABI > > compatibility very important. > > > > I can see, that your approach does not care too much... Otherwise, it looks > > good to me. It is closer to the Linux drivers infra, so it seems to be clearer > > then the current one. > > I did this on purpose. > From my point of view, we will have an API/ABI breakage in this code > at one point. > So I sent this mail to show where I'd like us to go, because this > looks saner on the mid/long term. [...] > > Another point is that the ethdev infra should not know about the > > underlying bus infra. The question is whether we do a big clean > > up (extract PCI-bus code out) or a small clean up (give the ethdev > > infra a hint which bus system it deals with). > > Yes, and I think these two choices are reflected by our two respective > proposals :-) Regarding the API/ABI breaks and how the big the changes must be, I'd say it is nice to have some changes without breaking the user interfaces. Though sometimes there is a great value to refactor things and break them. In such case, it is better to do the big changes at once so the breaking would impact only one version instead of breaking the same API again and again. About this proposal, I vote for: +1 [...] > > Moreover, there is no way how to pass arguments to pdevs, only to > > vdevs. This was shortly disscussed in [2] for the szedata2 PMD. > > > > [2] http://dpdk.org/ml/archives/dev/2015-October/026285.html > > Shorty discussed with Thomas, yes. > But after some experiments, it appears that you can pass devargs after > a whitelist option at init (--pci-whitelist > xxxx:xx:xx.x,whataniceoptionwehavehere=1). > This does not work for hotplug. > This is undocumented and this looks like a workaround, so I would > prefer we come up with a better api for 2.3. Yes we need also to redefine the command line syntax to have a generic way of passing per-device parameters to the drivers.