From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) by dpdk.org (Postfix) with ESMTP id F2A732BA9 for ; Mon, 23 Apr 2018 10:07:23 +0200 (CEST) Received: by mail-it0-f46.google.com with SMTP id t192-v6so8686584itc.1 for ; Mon, 23 Apr 2018 01:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fYSIJcCQhPAItlqmEEwh3t5BZgZU/4QnxUHUj4mUWDo=; b=J2mtvPZgxY9/hdO/KarEQr4s6uxfz5UhKs4mKcxAM3cfQzX3joIlNwrw42igDgz42M 7XNIDZu7mumRIkzF2rpW/gZ3adNVlmFhIGHiyMz7dyTplvrQ8K3jZ7MmhwWugF2Nq6bF Uw8MMvIzfNOn8JJOj1scG0aKtIWsmW1fqPf9JVU8VGqjBDkyleV2d5zAJnvkkrHt+szN EPozoQ53nFDMYCzs6BlI09aedi63hJ6A0A43xtut7mjH3ts2yd3PlD9f9+TC41TmyCtM XGYs7ZCn5I4TB89k3eomZn935+uGkv7j1kpxx0X5XDaz2SK+Q8zIh3A6KW/Jznvkk7cc sQsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fYSIJcCQhPAItlqmEEwh3t5BZgZU/4QnxUHUj4mUWDo=; b=GaU2iAqxQWpl+EeSlqIC7pztkHLOSg3Op/hJt/mHCIxYr5E4o4vYKa2h5vfTuHFVgJ U1DogP9mm5D/MtkLPXnFtZ53pJM0WrH+YO7L+a4I0jeWhFJ9MtVniF9uPtNdUlYnkzag Cw2E2Moauuwn0/u5zvuGvTeBpUKMKYThTG8ux0ycdinEjf3G3P89haMcGYW4Sxvd13sh RzHoKv4SqjIKFWTAzvBaEoi+FGAhuwqvhv7j/GViia/N1bCtNbFrYHzXQQ2zIqRvJHq8 Lfdq7ZTNnJR24mSUp/LblqdCx/wbMOpMtPCOa2cDdr6rtIQ2OXfWaydfOvse26taEju+ Lxbg== X-Gm-Message-State: ALQs6tCXlh3+GZGK2PS8Th+CB19RKQJXD2RK22OD2I9EbnUk/GcH77WC NK2NXYl1U1guTa69Of2ljbJu4/pyXwfTVb9TMm+O9A== X-Google-Smtp-Source: AB8JxZoDWc1pTNFQsl1LmIAwhk90MiKn/XsvYt8iRgLlPzTeiaNFZ4Nkj1VTGL5TOuih49c1neSScusTcW2zLyRF9zU= X-Received: by 2002:a24:7dcc:: with SMTP id b195-v6mr13023065itc.149.1524470842932; Mon, 23 Apr 2018 01:07:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.145 with HTTP; Mon, 23 Apr 2018 01:07:22 -0700 (PDT) In-Reply-To: References: <1524117669-25729-1-git-send-email-arnon@qwilt.com> <1524117669-25729-11-git-send-email-arnon@qwilt.com> From: Arnon Warshavsky Date: Mon, 23 Apr 2018 11:07:22 +0300 Message-ID: To: Aaron Conole Cc: Thomas Monjalon , "Burakov, Anatoly" , "Lu, Wenzhuo" , "Doherty, Declan" , jerin.jacob@caviumnetworks.com, Bruce Richardson , "Yigit, Ferruh" , dev@dpdk.org, Kevin Traynor Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v4 10/11] eal: replace rte_panic instances in init sequence X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 08:07:24 -0000 > > Looking at the eal_thread_init_master, I think it's probably a > recoverable condition. For instance, perhaps the core mask was wrong, > and could be corrected by re-attempting the initialization. Just > suggesting that it's probably okay to allow a re-attempt here. I would > suggest: > > - eal_thread_init_master(rte_config.master_lcore); > + if (eal_thread_init_master(rte_config.master_lcore) != 0) { > + rte_eal_init_alert("Cannot assign master lcore\n"); > + rte_errno = EINVAL; > + return -1; > + } > > if you agree. > > Yes. This is indeed the way to go. > > -- > > In the above I hope it illustrates what you'll need - a way to signal to > each side that initialization phase is happening, and that > initialization was successful / failed, and to clean up in the failure > case. > > Just meant for illustration so feel free to ignore / flame, but that's > how I would go about removing the rte_panic() calls. > Thanks. Indeed I did not consider recovery and clean up from here > > > This seems to only exist as a way of triggering the run_once check in > > the eal_init. It doesn't add anything except one more state variable to > > check against. What is the purpose? > > > > > > Actually this is not a run-once in purpose, rather an attempt to define > a state for the device > > and on the way work around breaking abi on the the void function called > before that. > > I think it's a way to try and track state for initialization and to > prevent future inits. Which ABI are you worried about? rte_panic()? > I'm not sure how this is an ABI work around, but I'm probably not > thinking about it hard enough. > I now see the mess I did and why wasn't it clear. I initially changed the api of eal_thread_init_master() from void to int. Having had the ABI check failed, I only fixed the linuxapp back to void and added this workaround to prevent ABI break on this patch. I will align both linuxapp and bsd to remain at panic for this function as well , and address it together with the thread itself -- *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon@qwilt.com *