From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by dpdk.org (Postfix) with ESMTP id 2EDFEC384 for ; Mon, 11 May 2015 12:16:17 +0200 (CEST) Received: from Charizard.fritz.box (unknown [212.224.70.43]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 5905018C62F2; Mon, 11 May 2015 12:16:16 +0200 (CEST) Message-ID: <55508170.90606@net.in.tum.de> Date: Mon, 11 May 2015 12:16:16 +0200 From: Paul Emmerich User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Luke Gorrie References: <554FF482.9080103@net.in.tum.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] TX performance regression caused by the mbuf cachline split 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: Mon, 11 May 2015 10:16:17 -0000 Hi Luke, thanks for your suggestion, I actually looked at how your packet generator in SnabbSwitch works before and it's quite clever. But unfortunately that's not what I'm looking for. I'm looking for a generic solution that works with whatever NIC is supported by DPDK and I don't want to write NIC-specific transmit logic. I don't want to maintain, test, or debug drivers. That's why I chose DPDK in the first place. The DPDK drivers (used to) hit a sweet spot for the performance. I can usually load about two 10 Gbit/s ports on a reasonably sized CPU core without worrying about writing my own device drivers*. This allows for packet generation at interesting packet rates on low-end servers (e.g. servers with Xeon E3 1230 v2 CPUs and dual-port NICs). Servers with more ports usually also have the necessary CPU power to handle it. I also don't want to be limited to packet generation in the long run. For example, I have a student who is working on an IPSec offloading application and another student working on a proof-of-concept router. Paul *) yes, I still need some NIC-specific low-level code (timestamping) and a small patch in the DPDK drivers (flag to disable CRC offloading on a per-packet basis) for some features of my packet generator.