From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: ixgbe TX function selection Date: Tue, 1 Mar 2016 19:18:31 +0000 Message-ID: <56D5EB07.9070706@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: dev@dpdk.org 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) 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) List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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