From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Emmerich Subject: Re: TX performance regression caused by the mbuf cachline split Date: Mon, 11 May 2015 12:16:16 +0200 Message-ID: <55508170.90606@net.in.tum.de> References: <554FF482.9080103@net.in.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" To: Luke Gorrie 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) In-Reply-To: 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 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.