From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by dpdk.org (Postfix) with ESMTP id 63748568F for ; Wed, 2 Sep 2015 22:50:42 +0200 (CEST) Received: by obcts10 with SMTP id ts10so19016017obc.1 for ; Wed, 02 Sep 2015 13:50:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vC/0e9sgeZCm/p+IKhwschors8aGm50LXbMR75oxeec=; b=e1JroLF+odICodwVnjl4oiHf+4LsDYvEWXQiuZ8/yAI36JQsRte+4LZYz5468dZS7g TLLlYN+r4qDSGdLbYw0iHTpkXDF+XzG6DLhNRiDjwFiAC/YDkDi+M4vGAnmPaTsqICjB AWcKmq6lWaHpVqXxyFwxSNUWez81sSQEaCECqg9MYzzLBR6MD0OXR+QmHnFjBEpRnW8j yQhrlP4kay4GUB7QYQQtzNVvGsnbMEfohx5ZqVwTFzgbOQbr8APTKtL1LfqITD7E1k/Y FtwuSH0MeBKtofzXHNMGk9+jyy6E0sDbFF4vReCOM7tSswbaGAavpD3EVWbmJ1n+hyWc o2ig== X-Gm-Message-State: ALoCoQlGB7y94XlWlcEz6nCPJ9X3r2mX/zCsOvuLoxcMZTKeXaSr7guhjy8JPIANYGJJi04+caw6 X-Received: by 10.60.130.136 with SMTP id oe8mr22329583oeb.10.1441227041200; Wed, 02 Sep 2015 13:50:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.209.6 with HTTP; Wed, 2 Sep 2015 13:50:01 -0700 (PDT) In-Reply-To: <20150902120039.69e3809c@urahara> References: <44e664970fef4bff942eaee5c7eaca67@bilemail1.empirix.com> <20150902125650.GA10364@bricha3-MOBL3> <3003120.8bdQ5bCz5C@xps13> <20150902120039.69e3809c@urahara> From: Marc Sune Date: Wed, 2 Sep 2015 22:50:01 +0200 Message-ID: To: Stephen Hemminger Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" , Don Provan Subject: Re: [dpdk-dev] rte_eal_init() alternative? 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: Wed, 02 Sep 2015 20:50:42 -0000 Stephen, Don, On Wed, Sep 2, 2015 at 9:00 PM, Stephen Hemminger < stephen@networkplumber.org> wrote: > On Wed, 2 Sep 2015 18:17:40 +0000 > Don Provan wrote: > > > Thomas Monjalon: > > >Yes but please, do not create an alternative init function. > > >We just need to replace panic/exit with error codes and be sure that > apps and examples handle them correctly. > > > > I understand your concerns, but the panics are really just the tip of > the iceberg of the EAL library not realizing it's a library. It really > makes no sense to think the library should define the application's command > line, or that the PCI bus should be probed without considering whether this > application is going to use PCI, and or to insist that EAL work be done on > internal EAL threads. > > > > So I'd say it's way past time to consider revamping initialization to > start the process of ending the DPDK library's tail wagging the > application's dog. Naturally this would have to be done while retaining the > existing init routine on top of a real library initialization, but that's > just an unfortunate artifact of the library's history, not a rational > design decision for moving forward. > That's one of the first things I was asking in the mailing list (argv): http://dpdk.org/ml/archives/dev/2013-August/000374.html I still think the same way. > > > > -don provan > > > > You are welcome to submit patches with what you are proposing for review. > Theoretical requirements discussions will probably only result in more > mail, > not new code. You know what you want, propose a solution. > > As far as the command line. That is easily managed by realizing the > application > doesn't have to pass the original command line into EAL. If you just view > the > command line as a way to pass unstructured options; the application or > infrastructure > can build up new values and pass it in. > Yes sure, and that's what all of us who are integrating DPDK in existing applications is doing: https://github.com/bisdn/xdpd/blob/stable/src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/driver.cc#L153-L157 But that's rather a workaround. Instead, having an eal_init() API which only handles a fixed set of arguments (non-argv) that can be used by existing applications, and build a command line API on top of eal_init() that parses argv as of now (e.g. eal_init_cl) seems to me cleaner. There are users that make use of the parsing of argv (e.g. dpdk-pktgen) in DPDK, so I think it makes sense to keep it. So if you'd agree on this general proposal, I will try to allocate some time for refactoring this. Marc > > I agree that initialization itself should try and not fail except in the > most extreme cases. "ie I can't find /sys what is wrong" and should try > and adapt more "you asked for 128 cpu's but I see only 2, log it and > continue" > >