From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id ED3602BA3 for ; Fri, 4 Mar 2016 13:00:01 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id l68so31566438wml.0 for ; Fri, 04 Mar 2016 04:00:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=FXECwnIDeCBE6310qZQY5pPmUCjiUSHN913PPVW/EQ8=; b=bWBeio/jFc9jRtXcRX92jpruFluVPUPvqt1U058STUSZlTo6NHBPpaw/07kHmt+QrI B4u8TKQKaRV0KY9g1jw3CZpgYB3YIBOqRLH4j6iqISY5Zwuo1UrRctZ448DlepgWcV4s FMOFrbqrJOpvBB+KaDxPmCQLZNv1nlgXgQVXU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FXECwnIDeCBE6310qZQY5pPmUCjiUSHN913PPVW/EQ8=; b=WS/jZjU0LwNddECHmTub7y3A0xXuh8j4odFTL10XIcUkxEiFBVaEzN15mfxc2CNK0D ke7sHm32g2MRXVwev60ivxwwncb0JgXOGmJL4seA6/V9vMZFYkrn91/Z9eG+zlTeJ6e0 b8cXDAHsDAQPzhA2NnvO+FR5ri+AseJTTSFAmE/vnteszFpL+N40jcSRzQdQdreplkdF UFUOG33SInB8A8vXkxuPLBJqFcQVm5TtB+Jd8mK0g138UmQl+bxRmA73J7KAiBrIzvqK VoBWEq3Tj1uTpo8B+7ZGBzG7QIwlWNVccqYdhF5wtXy+rBQcuNk45nPJj28kIqg/o3SA 0ueg== X-Gm-Message-State: AD7BkJLmGdgr6Llu9tLLr7Q14QOztKByJlVr84ZRTMpM7RA5J/QyVuPak/IkfbCEO0QvvchD X-Received: by 10.194.118.106 with SMTP id kl10mr281620wjb.154.1457092801764; Fri, 04 Mar 2016 04:00:01 -0800 (PST) Received: from [172.18.45.59] ([195.11.233.227]) by smtp.googlemail.com with ESMTPSA id o128sm2984484wmb.19.2016.03.04.03.59.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2016 03:59:46 -0800 (PST) To: "Lu, Wenzhuo" , "dev@dpdk.org" References: <56D5EB07.9070706@linaro.org> <6A0DE07E22DDAD4C9103DF62FEBC0909034378C2@shsmsx102.ccr.corp.intel.com> From: Zoltan Kiss Message-ID: <56D978B4.4020300@linaro.org> Date: Fri, 4 Mar 2016 11:59:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC0909034378C2@shsmsx102.ccr.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] ixgbe TX function selection 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: Fri, 04 Mar 2016 12:00:02 -0000 On 04/03/16 01:47, Lu, Wenzhuo wrote: > Hi Zoltan, > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zoltan Kiss >> Sent: Wednesday, March 2, 2016 3:19 AM >> To: dev@dpdk.org >> Subject: [dpdk-dev] ixgbe TX function selection >> >> Hi, >> >> I've noticed that ixgbe_set_tx_function() selects the non-SG function even if > Thanks for let us know the problem. But I don't catch your point. Do you really mean TX here? After a quick look at the code, I don’t find the SG/non-SG functions for TX. Do I miss something? The simple code path doesn't handle multisegmented packets. ixgbe_txq_vec_setup() and ixgbe_xmit_pkts_simple() doesn't even check the next pointer of the mbuf, just put the first one on the descriptor ring, and when TX completion happens, the memory is leaked because it just sets ->next to NULL, and calls rte_mempool_put[_bulk] ixgbe_xmit_pkts() puts all the segments on the descriptor ring, therefore when the descriptors are released they are released as well. This is what these functions supposed to do, but my point is it's very easy to send a multisegmented packet to the simple code path. > >> (dev->data->scattered_rx == 1). That seems a bit dangerous, as you can turn >> that on inadvertently when you don't set max_rx_pkt_len and buffer size in >> certain ways. I've learnt it in the hard way, as my segmented packets were >> leaking memory on the TX path, which doesn't cries if you send out segmented >> packets. > Which one will cause problem? SG or non-SG packets? And where does the memory leak happen? > >> How should this case be treated? Assert on the non-SG TX side for the 'next' >> pointer? Or turning on SG if RX has it? It doesn't seem to be a solid way as other >> interfaces still can have SG turned on. >> >> Regards, >> >> Zoltan