From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 9CF74275D for ; Tue, 1 Mar 2016 20:18:32 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id n186so52763954wmn.1 for ; Tue, 01 Mar 2016 11:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=+E9rHD2OGeQCLjucP82IeYfKCKDydmwr+5wR8FdXRqg=; b=aEhXZl/vbUxovINy3nxk5zemPBJRQ0zcjMoOxviCsMdAr/06BEltYebeFdYwLI5KX8 lPX9VkWu2a6B4e2/SQKWZD8kMnJI4QZOS1P2CDcmVPQCQNDJcKFWk0BUnskMrGKJfbC/ JsFb+TSItTtuH87hKOzOchhwut4/Oyy+3Ub2Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=+E9rHD2OGeQCLjucP82IeYfKCKDydmwr+5wR8FdXRqg=; b=K7gmOjYOBQ9Lf5kWVGKpN3yq3ZfBK4cuMOB3PWzMAnRjwd1gWxtuQzVuVnVeXhTMjs SrpAdBSF4qpeb19wJbN6zUnJnoWKrdj+WO13SJ9GuOfWwsr9y0FJgqxTFlMOe0zjWunE erosb7jb5fW5RDMIrv0dM7gU7OLaIvAfUtFnIGCdj9MhlINfNA3JZothvwLoF1sScei/ fV0pu/ZEApFUiaM9bwVTxh8kFAs+y4sqtYUjbWBVmPQZPOV8kj6TaEFye0frBtKTR+9v 3F32eOb7XnPxJRws4ha8cEmyf6TC3gnye/f/WqEx2LPsnZumYCkpYsPk26b4yIV4p8zg 0b1A== X-Gm-Message-State: AD7BkJLgXE8kUDjfml5HSXetroh9MCuV+rOIicl5Ye6l0/ZjTkr8FEuwgpG8QobI+hjnbIc6 X-Received: by 10.28.5.203 with SMTP id 194mr648369wmf.101.1456859912446; Tue, 01 Mar 2016 11:18:32 -0800 (PST) Received: from [172.18.45.59] ([195.11.233.227]) by smtp.googlemail.com with ESMTPSA id av3sm32369867wjc.44.2016.03.01.11.18.31 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 11:18:31 -0800 (PST) To: dev@dpdk.org From: Zoltan Kiss Message-ID: <56D5EB07.9070706@linaro.org> Date: Tue, 1 Mar 2016 19:18:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [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: Tue, 01 Mar 2016 19:18:33 -0000 Hi, I've noticed that ixgbe_set_tx_function() selects the non-SG function even if (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. 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