From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 125FD2BA1 for ; Mon, 11 Jul 2016 12:19:54 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id f126so84010256wma.1 for ; Mon, 11 Jul 2016 03:19:54 -0700 (PDT) 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:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=aylmCt4mbLdGvNkDGo7h2HsOrAQHGPjy9OSoIWVw1wk=; b=gCHIRZ8g4rhWrAnZ1axu7inT/lrWe967E50G8wHPstflZ898zrODmI2/MsAuTO6KXr wYx4GX4Xu+0gBbnNdkCGdoxJ/1GxWyF/f9pr3cGVFasQwgtjcrfSwJ60yLurN4TlFxq2 wf+BFewgX9M3Kd27FMjlEjF0L/ERZb8Xh7ucmxi+h3pJU1xSaprIGUn19vcChWK/VqGK KoBjtMzBiY6UKRYXLWWmNCOcXBdHoWlYJaVOm6qL1CzkjSB8rPR2/WxbypTFiMKuKkiy D6FbYodQ6CgtZTa3KdBRVtM5wiq5SgeH26tRCtb296j+XSMLa8RIBAAV/43iAXT/18Vc 55qg== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=aylmCt4mbLdGvNkDGo7h2HsOrAQHGPjy9OSoIWVw1wk=; b=Muc2NLW4MsyaVYnRLxhmQU5MGwACgN16qf9gOG5YM1pYREW4A4K95tSDOfEcs3BrFM M1Zk/DH98LU6X0hJH4tpI4ojLvFo2Bx6QpwH2qoICBykLMGSTgNtJ0mcVXKT1kRoIk5u ouv3BJ8Ho4PsjcyUbN/lqwgyR3jvdgr/aDl5R132oJZsKQdhzbl3X/EOPTQU/LksCkl9 1VvKYTVZsu7dgl0S9r+rpMLzuO/SPNyhopKy9xHecGNOwvj2C2xBT8tg3ievzyYslrn6 ykBQV9vKPAHEPJ6I4F0oRYqMryF92VdGfUH8lUxnXDww8oA5GT3bk8jOQ+2QJzUHeTnK 8cYQ== X-Gm-Message-State: ALyK8tL1FOgGMlE0nxM03cz1Lu50NVBfY+bvVe2GNe+bw1exCZLtFc7RzcpVsWA+qxDgBnan X-Received: by 10.28.10.196 with SMTP id 187mr19230479wmk.48.1468232393769; Mon, 11 Jul 2016 03:19:53 -0700 (PDT) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id q187sm174219wma.17.2016.07.11.03.19.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2016 03:19:52 -0700 (PDT) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: "Lu, Wenzhuo" , dev@dpdk.org Date: Mon, 11 Jul 2016 12:19:31 +0200 Message-ID: <10057084.veiWr8cPc7@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <2601191342CEEE43887BDE71AB97725836B7C7F1@irsmsx105.ger.corp.intel.com> References: <1468218079-8064-1-git-send-email-wenzhuo.lu@intel.com> <1927507.Pj5eqIlGbv@xps13> <2601191342CEEE43887BDE71AB97725836B7C7F1@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] specific driver API - was bypass code 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, 11 Jul 2016 10:19:54 -0000 2016-07-11 09:56, Ananyev, Konstantin: > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > > > > Hmmm. It's true it is cleaner. But I am not sure having a generic API > > > > for bypass is a good idea at all. > > > > I was thinking to totally remove it. > > > > > > Why to remove it? > > > As I know there are people who use that functionality. > > > > > > > Maybe we can try to have a specific API by including ixgbe_bypass.h in > > > > the application. > > > > > > Hmm, isn't that what we were trying to get rid of in last few years? > > > HW specific stuff? > > > > Yes exactly. > > I have the feeling the bypass API is specific to ixgbe. Isn't it? > > As far as I know, yes. > > > As we will probably see other features specific to only one device. > > Instead of adding a function in the generic API, I think it may be > > saner to include a driver header. > > But that means use has to make decision based on HW id/type of the device, > the thing we were trying to get rid of in last few releases, no? Not really. If an application requires the bypass feature, we can assume it will be used only on ixgbe NICs. Having some generic APIs helps to deploy DPDK applications on heterogeous machines. But if an application rely on something hardware specific, there is no benefit of using a "fake generic layer" I guess. > > Then if it appears to be used > > in more devices, it can be generalized. > > What do you think of this approach? > > We talked few times about introducing sort of ioctl() call, to communicate > about HW specific features. > Might be a bypass I a good candidate to be moved into this ioctl() thing... I don't see how making an ioctl-like would be better than directly including a specific header. > But I suppose it's too late for 16.07 to start such big changes. Of course yes. > If you don't like bypass API to be a generic one, my suggestion would be > to leave it as it is for 16.07, and start a discussion what it should look like > for 16.11. That's what we are doing here. I've changed the title to give a better visibility to the thread.