From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id DC6C8A0096 for ; Thu, 6 Jun 2019 04:08:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 05A811B947; Thu, 6 Jun 2019 04:08:04 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 5DF154CA6 for ; Thu, 6 Jun 2019 04:08:02 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2019 19:08:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,557,1549958400"; d="scan'208";a="182149209" Received: from yexl-server.sh.intel.com (HELO localhost) ([10.67.110.206]) by fmsmga002.fm.intel.com with ESMTP; 05 Jun 2019 19:08:00 -0700 Date: Thu, 6 Jun 2019 10:07:46 +0800 From: Ye Xiaolong To: "Li, Xiaoyun" Cc: "Wu, Jingjing" , "Wiles, Keith" , "Liang, Cunming" , "Maslekar, Omkar" , "dev@dpdk.org" Message-ID: <20190606020746.GA12207@intel.com> References: <20190603084611.40931-1-xiaoyun.li@intel.com> <20190603084611.40931-5-xiaoyun.li@intel.com> <20190604064801.GA94383@intel.com> <20190605092512.GA4003@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH 4/6] examples/ntb: enable an example for ntb 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" On 06/05, Li, Xiaoyun wrote: >> >> Yes, I agree, but I don't think it is the case here. >> >> >It will cause segment fault in enqueue/dequeue. >> >> Hmm, have you debug it? Which line caused the segfault? >> >> You can refer to test_rawdev_enqdeq function in skeleton_rawdev_test.c, what >> it does is similar to my suggestion, and you just need one alloc/free. >> >Of course I debug on it. It will cause seg fault at rte_memcpy. Because buffers[0]->buf_addr is not right. >You can see the debug log. >(gdb) p test_pkts_send[0].buf_addr >$3 = (void *) 0x5555562784c0 >(gdb) n >164 rte_rawdev_set_attr(dev_id, "spad14", val); >(gdb) >ntb_attr_set(): Set attribute (spad14) Value (0) >165 val = size; >(gdb) >166 rte_rawdev_set_attr(dev_id, "spad15", val); >(gdb) >ntb_attr_set(): Set attribute (spad15) Value (35) >175 rte_rawdev_enqueue_buffers(dev_id, (struct rte_rawdev_buf **)&test_pkts_send, 1, (void *)size); >(gdb) > >Thread 1 "ntb_fwd" hit Breakpoint 2, ntb_enqueue_bufs (dev=0x555556023b80 , buffers=0x7fffffff7fe0, count=1, > context=0x23) at /home/xiaoyun/ntb/dpdk-next-net-intel/drivers/raw/ntb_rawdev/ntb_rawdev.c:244 >244 struct ntb_hw *hw = dev->dev_private; >(gdb) n >248 if (hw->ntb_ops->get_peer_mw_addr == NULL) >(gdb) >249 return -ENOTSUP; >(gdb) p buffers[0]->buf_addr >$4 = (void *) 0x6f77206f6c6c6568 >(gdb) p &buffers[0]->buf_addr >$5 = (void **) 0x5555562784c0 Hmm, you're right, after a second thought, we do need double alloc/free in this case, my bad. Thanks, Xiaolong > >> Thanks, >> Xiaolong >> >> > >> >I will free twice. >> > >> >> > >2.17.1 >> >> > >