From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com [209.85.192.172]) by dpdk.org (Postfix) with ESMTP id BB6551B27E for ; Thu, 12 Oct 2017 14:14:15 +0200 (CEST) Received: by mail-pf0-f172.google.com with SMTP id e64so4504403pfk.9 for ; Thu, 12 Oct 2017 05:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cMT6ZrRiLb4FJe5gzJ9nbCC33FhxNM+6thIFkL0oz2o=; b=htdphHYw2NebSorwJ4gbYcaznJ/3VbhLZAh3SOR5d53YwbbFoEG4S9CbBhrFpsVtX6 nu+SN7iE0orHzv/MG+b0tfdvIVA/qmEptO5zP9seJnFOsZ0KwLqlLemNOaxYsVzMcp1S xl04fngYELLDvBgjBPKb7Ad2QGN6EWu2pKg5aRdAv3ItYPPjHYrs6URU34A3HzQWUgbX vf7AWmPWhbHrY1NJzN58Xpg5xMqd1R6941tDAJuYHH+XWUCscj+RKyxf+ZDqnBkJ2MB/ XgumbIMGo2JRQdVGlUJLktLQoVBvuhuQu1oK7f7G3mRzl4pwo7QLlLA2GOwGxAKsl7+p 3Y6w== 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=cMT6ZrRiLb4FJe5gzJ9nbCC33FhxNM+6thIFkL0oz2o=; b=Znl8wuwXM8CXbMy0reCYDeh90W3e7ADNKyWSLVWkg/TMhA/P/WxCfppdsOV/0dryXu 2DW7igWu4TMP6Bgjx+vGpcQxlVYDi1PWVwhKu31Bd7FNYqD+NAiIElaClPg1Dm+6098M nSzJd6DgofJ5ynxHC6pNF4Ci8rhmU9T+B9TTfkkzLnchAISPhsjsv3z5PDAvWNoR9nuZ jirpQy2LwhfVM9vuGOibzFghuaZtpaKjPx+5l8YbtJGD6/kpmLvFKoPHs+/ahr05/Bfq TjqzGJHjcWB/7huFTECWZ/C3g0URD9hhIaLEk1FhBBGI7CtA0l0NzhfHZO15fmTbWH6e zQ4w== X-Gm-Message-State: AMCzsaU1zpObdoLcADvhpmNvWPV22OD6ISLqntdugUuwM2tQjWvmkfuB PyBcqhkCgOwJKyNixZ+7IZTsDpeZXy9XwpKjVgFjmg== X-Google-Smtp-Source: AOwi7QAv0t5CSO+B2PA26jrpZyG7HYyE2obvPJLxWgraxhRC1LEAlAOqaKIjVhDDrYEmTcPz7BW73X6k0sJArxY2Mr8= X-Received: by 10.99.158.82 with SMTP id r18mr57905pgo.349.1507810454733; Thu, 12 Oct 2017 05:14:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.143.196 with HTTP; Thu, 12 Oct 2017 05:14:14 -0700 (PDT) In-Reply-To: <6bfe47de-c5b4-2b01-7991-2ac48913b2c3@6wind.com> References: <1507031500-11473-1-git-send-email-tdu@semihalf.com> <1507561244-20115-1-git-send-email-tdu@semihalf.com> <1507561244-20115-3-git-send-email-tdu@semihalf.com> <9041127.34t6OW5FrT@xps> <20171012065104.GC19106@tdu> <6bfe47de-c5b4-2b01-7991-2ac48913b2c3@6wind.com> From: Jacek Siuda Date: Thu, 12 Oct 2017 14:14:14 +0200 Message-ID: To: Vincent JARDIN Cc: Tomasz Duszynski , Thomas Monjalon , dev@dpdk.org, Marcin Wojtas , Dmitri Epshtein , Natalie Samsonov , Jianbo.liu@linaro.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v4 02/16] net/mrvl: add mrvl net pmd driver skeleton 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: Thu, 12 Oct 2017 12:14:16 -0000 Hi, The problem is, that both drivers are totally separate entities, linked into separate libs, but we need to use only one setting in both of them. So, in order to provide any runtime (or even compile-time) verification, we would need to create a third entity just to handle a simple assertion - a bit overkill. At the time the code was written, common configuration option seemed the most logical. If your long-term goal is to get rid of build-time configurations, then it puts everything in a different perspective. What we can do, is to add a run-time driver option and oblige user (in documentation) to set the option only for the first mrvl vdev. If the driver doesn't see the option set, it won't initialize DMA. This, plus meaningful error handling/logs should take care of any potential mishandling by user that we were afraid of. I hope that would be more acceptable. Best Regards, Jacek Siuda. 2017-10-12 9:59 GMT+02:00 Vincent JARDIN : > +1 with Thomas, see below, > > Le 12/10/2017 =C3=A0 08:51, Tomasz Duszynski a =C3=A9crit : > >> What is MUSDK_DMA_MEMSIZE? >>> If the value cannot change, it must be a constant in the code. >>> If it can change, it should be a run-time driver option. >>> >> It's up to the user what MUSDK_DMA_MEMSIZE is going to be. Currently it'= s >> set to value that should work it all cases. >> >> Except that, MUSDK_DMA_MEMSIZE is used as synchronization point for net >> and crypto (on condition they are used together i.e ipsec-secgw). >> >> Suppose we have two different MUSDK_DMA_MEMSIZE defined for net/crypto >> then >> dma memsize allocated will depend on driver probing sequence which might >> confuse user. >> > It does not make sense, > + /* > + * ret =3D=3D -EEXIST is correct, it means DMA > + * has been already initialized (by another PMD). > + */ > + ret =3D mv_sys_dma_mem_init(RTE_MRVL_MUSDK_DMA_MEMSIZE > > int mv_sys_dma_mem_init(u64 size) > { > struct sys_dma *i_sys_dma; > int err; > > if (sys_dma) { > pr_err("Dma object already exits.\n"); > return -EEXIST; > } > > So, I do not understand why you cannot add some checks into the drivers t= o > assert that users must have set the same value for both when calling: > ret =3D mv_sys_dma_mem_init(my_best_size); > maybe, you need to fix and improve musdk first to avoid DPDK from getting > such compilation issues. > > best regards, > Vincent >