From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by dpdk.org (Postfix) with ESMTP id 9F7D53796 for ; Tue, 24 Mar 2015 18:42:10 +0100 (CET) Received: by wibdy8 with SMTP id dy8so81378585wib.0 for ; Tue, 24 Mar 2015 10:42: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 :subject:content-type:content-transfer-encoding; bh=l275tIiaTnk0IPp7dtZEnT5w+Li5jkF2GIHxlnDLQzo=; b=NwaL9tMBzGlqBEqL3C8kWn3y7nqrawH2Qrk5puxRLzPYGVCqDiDThc6W4moYu5fws2 P4oLTb0tT5c5d5ZBwTzdUgYvjrPqwknUIP7uWTvvMDHJJgnebBiQc+OzybX7TtVP5urS fA10e04wEhNZNv3tMjKHjK8t37vjhUzSmHB1fNM0uk4hFeShtv5WDTZTxyrwRKnH6uJK yY10d5EB7v+D+uOlro0FNiTIAt7PYUE0k+Bn/aBpb193P9hzrnj6nQrXMqR5g9yHFxl/ WyWrajjrlYG5xaoJdm/BvGmm7u49Gr5iGPqNfSMsS9LQri7QLlp5lWwnSiRvlgMOC674 xEsA== X-Gm-Message-State: ALoCoQnR6ccmpSRhxSHVDrvnveRNz+xil1T37I7HnQw4BGWGdMBzUQdaD1p3/SYUxhRYSrsXvOIc X-Received: by 10.194.61.161 with SMTP id q1mr10380351wjr.132.1427218930366; Tue, 24 Mar 2015 10:42:10 -0700 (PDT) Received: from [192.168.0.101] ([90.152.119.35]) by mx.google.com with ESMTPSA id hn8sm496087wib.18.2015.03.24.10.42.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 10:42:09 -0700 (PDT) Message-ID: <5511A1F0.40605@linaro.org> Date: Tue, 24 Mar 2015 17:42:08 +0000 From: Zoltan Kiss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dev@dpdk.org, dev@openvswitch.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 Mar 2015 01:04:31 +0100 Subject: [dpdk-dev] ovs-dpdk: placing the 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: Tue, 24 Mar 2015 17:42:10 -0000 Hi, I've noticed in lib/netdev-dpdk.c that __rte_pktmbuf_init() stores the packet metadata right after "struct rte_mbuf", and before the buffer data: /* start of buffer is just after mbuf structure */ m->buf_addr = (char *)m + sizeof(struct dp_packet); (struct dp_packet has the rte_mbuf as first member if DPDK enabled) However, lib/librte_mbuf/rte_mbuf.h seems to codify that the buffer should start right after the rte_mbuf: /** * Given the buf_addr returns the pointer to corresponding mbuf. */ #define RTE_MBUF_FROM_BADDR(ba) (((struct rte_mbuf *)(ba)) - 1) /** * Given the pointer to mbuf returns an address where it's buf_addr * should point to. */ #define RTE_MBUF_TO_BADDR(mb) (((struct rte_mbuf *)(mb)) + 1) These macros are used for attaching/detaching mbuf's to each other. This is the way the code retrieves the direct buffer from an indirect one, and vica versa. I think if we want to keep the metadata feature (which I guess is quite important), we need to add a pointer to rte_mbuf, which helps the direct and indirect structs to find each other. Something like: struct rte_mbuf *attach; /**< Points to the other buffer if this one is (in)direct. Otherwise NULL. */ What do you think? Regards, Zoltan Kiss