From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9B8AEA0553; Mon, 17 Feb 2020 13:53:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DD1681DAA1; Mon, 17 Feb 2020 13:53:18 +0100 (CET) Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by dpdk.org (Postfix) with ESMTP id 7F73F1DAA1 for ; Mon, 17 Feb 2020 13:53:17 +0100 (CET) Received: by mail-pg1-f196.google.com with SMTP id g3so8973759pgs.11 for ; Mon, 17 Feb 2020 04:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CRyDj68la2vyzBzCXRn3wT8+RBNzKwtUmEOqIg24aZU=; b=ukIMNDkULw4FsgQ0tMOQhM0h8MnqsvMBuvVKtt8gw5p7N3+sJSn0+C49layFlUYR7A c+6HRsCogTbnEkZCu5CrIhXkyN1TT1nyfcYKVssWjOIg+kDAc7UWsL/a/cshhTJGslOf 1JdgFpBEwze289cVVYmIwwDDLVkLbwroL7oL9Wln/pytJ31eFRE4LjMxCOt7zTeM9ylu gJOVfFGuowj4mbhVt0vEbfgk9UW9GRQTsyzoEs63I/T4BJE6R6XYC8xEFhKraUc/BDel +FWHL4PmmnN4B0lUyNPS30L5zqEHLr114IdTFjo3qo8EMpvAZnm5YFh0C+6mDFSlEkOR wLYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=CRyDj68la2vyzBzCXRn3wT8+RBNzKwtUmEOqIg24aZU=; b=M4Vf6uOvhEI5q8r3WamOfcneC8ktqX4dgVC8Bb9Hq6683bpbYYlUQF7qSqvCz1u2o6 2ADkTtxzOQj2uqy0tZOxLx9NizD5va5MDfcdJGb/6rCpC5SmchdW2InffjIm65UhyKGu Iu2D5KR9SipzoiRSqk2jDGE99t+/6mtnaqX9qXpnEpxbMUWqf8/lxcNuhU9vPZ10gAEQ nDJ1/lutBYZNjXUWbWQGLsBb/72BqJOGRWvqoXhi0nWkZhqClsClcUJi9MeSKHiLTY8t Ins+1z6ij1cr76oxxwz4WxgQct1dHl2bH1du0kj+RxO6FAKWwEju8q+d3QvnfWil6hZg 7hBw== X-Gm-Message-State: APjAAAXILmCQv7ccwyAfAgFE3PQ8yrbZ1TCrSY/fEaDeQw1EQfeF76gr bhhTTCAs94XTtveVUKoMI/EMh6PZ X-Google-Smtp-Source: APXvYqzpGWrikHCon/aJbwUXTcmU5eEIft5xqTmaT7CVgw0aARd9eRlBM2n5rucSGOLSo+NIi2qu6Q== X-Received: by 2002:a65:5ccc:: with SMTP id b12mr17435388pgt.124.1581943996108; Mon, 17 Feb 2020 04:53:16 -0800 (PST) Received: from [172.30.202.27] ([192.47.164.146]) by smtp.gmail.com with ESMTPSA id f43sm560585pje.23.2020.02.17.04.53.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Feb 2020 04:53:15 -0800 (PST) From: Yasufumi Ogawa To: Thomas Monjalon , David Marchand Cc: "Burakov, Anatoly" , "Ananyev, Konstantin" , dev References: <20191113214346.33749-1-yasufum.o@gmail.com> <6ea0b73a-1d38-dbe1-2142-9ab4fec594e7@gmail.com> <1776149.MyG8hOvIyE@xps> Message-ID: <62b4a241-8edc-7b86-ecc8-3f9640b7be02@gmail.com> Date: Mon, 17 Feb 2020 21:54:02 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <1776149.MyG8hOvIyE@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v8 1/1] fbarray: fix duplicated fbarray file in secondary 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > 14/02/2020 16:08, David Marchand: >> On Fri, Feb 14, 2020 at 8:46 AM Yasufumi Ogawa wrote: >>> >>> Hi, >>> >>> Could I confirm that this patch is going to be merged in 20.02? >> >> Sorry, but I can't take this patch in 20.02. >> It breaks compilation on FreeBSD. >> http://mails.dpdk.org/archives/test-report/2019-November/109435.html Sorry. I didn't find it. I'd see it. >> >> >> I am still unconvinced on the need to change the size to something so >> huge to accommodate with this new use case (secondary processes in >> containers). It is not so common actually, but serious issue for some NFV usecases. I remember, in a talk in the last DPDK summit, ZTE was also suffered from the same problem. >> Why can't we truncate the container hostname so that it fits in 64 bytes? It is just a possible maximum length of format of "fbarray_memseg-1048576k-0-0_PID_HOSTNAME", so I think it can be truncated if dropping some information. >> >> >> Thomas, opinion? > > If the use case is justified enough, I would prefer merging such change in > 20.11 avoiding an ABI breakage in a core library, even if it is experimental.I understand, thanks. Yasufumi