From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id 5ED1632A5 for ; Wed, 10 Sep 2014 17:26:01 +0200 (CEST) Received: by mail-wg0-f50.google.com with SMTP id x13so6359735wgg.33 for ; Wed, 10 Sep 2014 08:31:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QCMjc26DWol1CnHeRAfw9izSilWAxYgeI4MhDEM1dGM=; b=CYcVMed52tSBYHxiH883o0VKUdrWSga34YpRhNQNTLagsjSD7FQlxls3W3VKJZ4yLo Hg2oaD72L4CC2+zlFHGCjinap+Xf6qrJRNX9EXJpwPOJhRM9XQslpRuYdMxrRFbd72+r AGHLIRFthuhPZmi334RxD8/NDCmJXDhYsq53N3TfQXG6U6OyRuAAbzgdykWILqeVdqoM K47nnLdmLGg8b95RcitgObs8REjGcoLW2fTA4Ao0s3CAFF9EnmI6vIBv+AdFPfZMn5fk SZ1g1DK/UulaoMQhQG9x6jAm+ralscFleJ+x0mXE4mRuPWWuAP2v9z/4sMKxJO4QBgGq HXHQ== X-Gm-Message-State: ALoCoQmKTyjyQBLCMFp6Qbe68QE6cSiCnqcIB3ZmzGmxtJtIad6VuWEicrFLkDpIk97mqrkWly9G X-Received: by 10.180.72.239 with SMTP id g15mr12530729wiv.47.1410363070428; Wed, 10 Sep 2014 08:31:10 -0700 (PDT) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id bj7sm2452679wjc.33.2014.09.10.08.31.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 08:31:09 -0700 (PDT) Message-ID: <54106EBC.6040206@6wind.com> Date: Wed, 10 Sep 2014 17:31:08 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Bruce Richardson References: <1409759378-10113-1-git-send-email-bruce.richardson@intel.com> <1409759378-10113-8-git-send-email-bruce.richardson@intel.com> <540D9B95.3020504@6wind.com> <20140910150914.GA9656@BRICHA3-MOBL> In-Reply-To: <20140910150914.GA9656@BRICHA3-MOBL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 07/13] mbuf: use macros only to access the mbuf metadata 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, 10 Sep 2014 15:26:01 -0000 Hi Bruce, On 09/10/2014 05:09 PM, Bruce Richardson wrote: >> Just one question: why not removing RTE_MBUF_METADATA*() macros? >> I'd just provide one macro that gives a (void*) to the first byte >> after the mbuf structure. >> >> The format of the metadata is up to the application, that usually >> casts (m + 1) into a private structure, making the macros not very >> useful. I suggest to move these macros outside rte_mbuf.h, in the >> application-specific or library-specific header, what do you think? >> > > Things look to work if I just move the definitions en-masse into > rte_port.h. Is that the sort of change you would be thinking of? > I was wondering about replacing the typed macros here with a > generic one to access just beyond the definition of the mbuf > structure, but on further thought, I believe that using the > buf_addr pointer in the mbuf data structure is probably enough > for most applications. [An alternative to moving the definitions > into rte_port.h is to move them into rte_table.h and having > port_frag.c use the buf_addr pointer instead of a macro to get at > the metadata. All other references to the macros apart from two > in that port file, are in the tables or in apps that use the > tables lib.] > What do you think? Yes, moving the macros in rte_port.h looks good to me, since the libraries using rte_ports are the users of this specific metadata format. Thanks! Olivier