From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 38CFE1DEB3 for ; Tue, 12 Jun 2018 04:25:15 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id v16-v6so17859267wmh.5 for ; Mon, 11 Jun 2018 19:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=abOlKKzZsvzthJc6BuIo2HUMiJSEG7zYWkr7A8FmmK4=; b=q6a//Mxl4yT0bw/4j2rzx+xS/0GzVer8qqitmkPp6xpUUxZCxSBT3HmWZ4e2YXC6G6 sNaiLFsLc4PKwMV9zazpw4Xyl1UPBMhnISft0KSbWjF5zqORER84KDCv5HVD+9Hb3q2f 5+30Qt7xku1iCCsADYu//ypv5pkEafRvEa3Bb7RohnEPV/ekuqzQ7l4IxdAR7HxG5Xs0 DiH+ScLlyrPw+CBrLLEpi1L8K1KOE3lV4tTjKAu/vDKBsaboBZkXKc+NxIrAhIaBkq+T WdXKxhZRrDWqvVGL6Hag1nwjotJ9HDlYlQDxX6jIuiZtJS4nBQ9UHyJxD+ZmwzxAFCp8 Xx4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=abOlKKzZsvzthJc6BuIo2HUMiJSEG7zYWkr7A8FmmK4=; b=K4MtfKpdvIzGHBggEZW/F9l2NBmERN2Oml/eLOwLhdFpQwI2KtzXGpiftOg49HvDNs cTys6muDDrs8PB51Jvqg/F09rtiz+ksA1N5R7yGOqKfq5J9hCEt4Por3i9vZ9RnM3LC3 1ra3AxEk42RvsylRmhVTeRbKok+D1BAS32f7ReLaFIEPKpz16WG9vDYP4maC1FhbKmJK uUjkBIMnEPNNHr5MmfX3ELXYkod6wO7iHRUqXsOvoNPHv4y84fPxDk7fYdlsMWJuOUHl XF8zbx2dzFFeJHfOgcdzlxLPmgQIay2OmqoqqROfyRLDSnILRHru9eCILYsWGmPUGL27 r+GA== X-Gm-Message-State: APt69E0k5dsJJlo9AzUwfdqpvctEmm46AnQGt+NiZ3aBGFpE1nEQXnY5 3fol1r3/W7VpAtRyoDoRKFMKnClRHdSJRcNP35U= X-Google-Smtp-Source: ADUXVKLWdlS9FukJeOYBG8DADfL4q+BJdMs6ysUzXPJGaMh6VkxVDpZbg8XJvB/KNFeuWsrAnkPFOqYV32h3B/Bg5lw= X-Received: by 2002:a1c:f906:: with SMTP id x6-v6mr759054wmh.63.1528770315350; Mon, 11 Jun 2018 19:25:15 -0700 (PDT) MIME-Version: 1.0 Sender: dan.gora@gmail.com Received: by 2002:adf:e952:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 19:24:35 -0700 (PDT) In-Reply-To: References: <20180607235454.27832-1-dg@adax.com> <99f224eb-0470-78d2-a062-8dca4d4b7b1a@solarflare.com> <5F1328F1-6991-45EA-8DC2-300600702210@intel.com> From: Dan Gora Date: Mon, 11 Jun 2018 19:24:35 -0700 X-Google-Sender-Auth: f6GztOl9vcJvzzVNnVl2KmQ09Uw Message-ID: To: Andrew Rybchenko Cc: "Wiles, Keith" , "dev@dpdk.org" , Olivier Matz Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 1/4] mbuf: add accessor function for private data area 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: Tue, 12 Jun 2018 02:25:16 -0000 Hi Andrew, On Sat, Jun 9, 2018 at 2:23 AM, Andrew Rybchenko wrote: > BTW, thinking about function I found out there is a trap in private area > size related to the function. I think that the function description should > highlight that rte_pktmbuf_priv_size(m->pool) should be used to > find out the size of private area since indirect mbuf has size of the > direct private are in its priv_size (but we return pointer to the indirect > mbuf (the mbuf itself) private area here). > hmm... I guess I didn't realize that. I think that what I'm going to do is just remove the check for m->priv_size == 0 entirely. It seems like checking the priv_size is just going to cause more problems down the road than it is worth. The whole point of this was just to have a simple API function to access the private area, not to fully save the programmer from shooting him/herself in the foot by accessing a private data area which doesn't necessarily exist. thanks, dan