From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by dpdk.org (Postfix) with ESMTP id 7925C91E4 for ; Tue, 15 Sep 2015 11:16:19 +0200 (CEST) Received: by obbbh8 with SMTP id bh8so129628891obb.0 for ; Tue, 15 Sep 2015 02:16:17 -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:date :message-id:subject:from:to:cc:content-type; bh=kL6oPn+xC1gqM/vZ8XZ/xfdNTlGGLwVUg1huGkb3ciM=; b=AN3fYhCmvG4KXvuQ8iYDaBguQsKiTLyRY+5tp6n+ba+6p1oC+tWaf1F6v5KXkeNfVB XGoV2CmSf3cGuRBG4SsBym+uAki+PUqi7VJ2QzpKuDV/Fiqfiw3s4iu1jDEZn+tALzVz WaJ9wTBV62QDmdz5cMi0526N7WGDpfIfpRYHyULO0BkZue6OD1knFuxGQomHps+TWy9e G27VfefJNXxVJ6Xz9hGbRgRQEVXetcUj2gamk5aRwyHa4ZdsN7G5tBCImvBuMCfgVk0k 7O8vwl8O+Iy/GuwnXtIJjm6ssqcghEf1PmUBFdZuQObDQft8xCg7h7iA2RoMPJU7RoXc 9L6w== X-Gm-Message-State: ALoCoQmlXWfaVEHXngWnGoJNFql3CA0bwFNoMqbTMHbjJnYzlhpP6v2AkcmElLH8lVVFS0gMjte9 MIME-Version: 1.0 X-Received: by 10.182.16.198 with SMTP id i6mr3973494obd.48.1442308577725; Tue, 15 Sep 2015 02:16:17 -0700 (PDT) Received: by 10.76.150.166 with HTTP; Tue, 15 Sep 2015 02:16:17 -0700 (PDT) In-Reply-To: <1882381.9qlZTmz9zB@xps13> References: <1882381.9qlZTmz9zB@xps13> Date: Tue, 15 Sep 2015 11:16:17 +0200 Message-ID: From: David Marchand To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] DPDK 2.2 roadmap 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: Tue, 15 Sep 2015 09:16:19 -0000 Hello all, My turn. As far as the 2.2 is concerned, I have some fixes/changes waiting for going upstream : - allow default mac removal (to be discussed) - kvargs api updates / cleanup (no change on abi, I would say) - vlan filtering api fixes and ixgbevf/igbvf associated fixes (might have an impact on abi) - ethdev fixes wrt hotplug framework - minor fixes in testpmd After this, depending on the schedule (so will most likely be for 2.3 or later), I have some ideas on : - cleanup for hotplug and maybe discussions on pci bind/unbind operations - provide a little tool to have informations/capabilities on drivers (=C3= =A0 la modinfo) - continue work on hotplug By the way, I have some questions to the community : - I noticed that with hotplug support, testpmd has become *really* hungry on mbufs and memory. The problem comes from the "basic" assumption that we must have enough memory/mbufs for the maximum number of ports that might be available but are not in the most common tests setup. One solution might be to rework the way mbufs are reserved : * either we let testpmd start with limited mbufs count the way it was working before edab33b1 ("app/testpmd: support port hotplug"), then when trying to start a port, this operation can fail if not enough mbufs are available for it * or we can try to create one mempool per port. The mempools would be populated at the port init / close (?). Anyone volunteers to rework this ? Other ideas ? - looking at a patch from Chao ( http://dpdk.org/ml/archives/dev/2015-August/022819.html), I think we need to rework the way the numa nodes are handled in the dpdk. The problem is that we rely on static arrays for some resources per socket. I suppose this was designed with the idea that socket "physical" indexes are contiguous, but this is not true on systems running power8 bare metal (where numa indexes can be 0, 1, 16, 17 on quad nodes servers). I suppose we can go with a mapping array (populated at the same time cpus are discovered), then use this mapping array and preserve all apis, but this might not be that trivial. Volunteers ? Ideas ? - finally, looking at the eal, there are still some cleanups to do. More specifically, are there any users of the ivshmem feature in dpdk ? I can see little value in keeping the ivshmem feature in the eal (well maybe because I don't use it) as it relies on hacks. So I can see two options: * someone still wants it to work, then we need a good rework to get rid of those hacks under #ifdef in eal and the special configuration files can disappear * or if nobody complains, we can schedule its deprecation then removal. Thanks. --=20 David Marchand