From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by dpdk.org (Postfix) with ESMTP id 3CC9691D6 for ; Mon, 31 Aug 2015 16:24:09 +0200 (CEST) Received: by wibz8 with SMTP id z8so1999535wib.1 for ; Mon, 31 Aug 2015 07:24:09 -0700 (PDT) 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=/wcoiTHIjimyzcK2oJG7D5k3bLyeaAoiTxjLzBe7GvM=; b=RJTRP36CmDEVVupNl4UgMoPSBuubOC0jyb8pzH9sJjQ0sjtO621CDKeVq5+lawW1X5 0IybGsymb+kpflSjF8u3uXNA66GS4W57cIoBAyMX15XG43KJ3cG2RoVHviwweqmPiOHi JBbNuTvsiXeUoKA4bsUj3l8zlh1ntl1Qb2WSqSxQ5zbLV1zHndr0RRLCnotnBxHjAqrs XcgoNuqBFcctG8j68l6EausgaemNT9lXXKz4MpI/oeGkTxVmTetFA2oyUBt1/LeJ4bFD eyKv15oO4RrQlzEVLemylpAR5Do4Fc3mQFZp0eb/UpGEk429A6EgH7wpdWDbImoyAXY6 NM9g== X-Gm-Message-State: ALoCoQmyyU33MnabW8NxpUahrusLCV0UYToR+jVxRWUZUXx0XQ57lx/lrthneZeQfKRhxu5GDX2g X-Received: by 10.180.73.229 with SMTP id o5mr19111838wiv.36.1441031048967; Mon, 31 Aug 2015 07:24:08 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by smtp.gmail.com with ESMTPSA id du6sm18248181wib.24.2015.08.31.07.24.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Aug 2015 07:24:08 -0700 (PDT) From: Thomas Monjalon To: Neil Horman , "Iremonger, Bernard" Date: Mon, 31 Aug 2015 16:22:58 +0200 Message-ID: <2129387.iCBeS9Cg7R@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20150831125940.GC32518@hmsreliant.think-freely.org> References: <20150831125940.GC32518@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC PATCH 0/6] remove pci driver from vdevs 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, 31 Aug 2015 14:24:09 -0000 2015-08-31 08:59, Neil Horman: > On Mon, Aug 31, 2015 at 10:23:33AM +0000, Iremonger, Bernard wrote: > > The purpose of this RFC is to remove the need for a PCI device driver > > from Vdev's that that do not use a PCI driver. Removing the PCI driver > > is implemented in the ethdev changes. I have modified some of the Vdev's > > to verify that the ethdev changes work. > > > You didn't remove the relationship of the ethdev to the pci driver though, which > is really the problem, An ethdev may reside on any number of bus types > (pci/usb/vmbus/virt/none). This patch series just papers over the fact that an > ethdev is implicitly a pci device by making the assignment of its pci_dev > pointer optional. Whats really needed is a way to associate an ethdev with an > arbitrary bus > > > > What benefit accrues to those vdev > > > PMDs that implement this change? What penalty is imposed on those that > > > do not change? > > > > 6Wind have decided that only cleanup patches will be allowed in future Not a 6WIND decision. This is a community project. I gave my opinion regarding maintenance of the code. I may be wrong but after discussions with others and recent comments, it seems well justified. > > for Vdevs that have a dummy PCI driver. Any change in functionality for > > these Vdevs will not be allowed. > > Please see email below from 6Wind > > > > http://dpdk.org/ml/archives/dev/2015-July/022107.html > > > I think you misread that. I think all Thomas is asking for (correct me if I'm > wrong Thomas), is for someone to start refactoring the ethdev registration code > so that we can have a single init path without the need for wierd typing and > differentiation at init time. He's not going to stop accepting bug fixes for > existing drivers just because it uses the existing initalization infrastructure. Yes. Such cleanup can be enforced by rejecting new features on top of these workarounds. But driver fixes will be accepted. > I would even go so far as to say new drivers will be accepted for as long as the > existing init path exists as it does. We just need to start thinking about how > to make bus registration independent of ethernet device registration, and while > your patch series sort of eliminates some of that, its really not a proper > refactoring of the sort I think Thomas is asking for Yes The sooner will be the better :) Thanks for taking care of this issue.