From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by dpdk.org (Postfix) with ESMTP id CFBDC8E58 for ; Thu, 24 Sep 2015 21:10:42 +0200 (CEST) Received: by oibi136 with SMTP id i136so47005097oib.3 for ; Thu, 24 Sep 2015 12:10:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Vy9tA3ppwBauZoJ95bzcJ1T2Ny5ylcK7gNof8lYkJn8=; b=UemAQgrYV39RfYSSsn4tdHn0WsRI4JT/K141uVOUPKzB0E1aoY54qYHfg/FsCM1W/D TaV2f3ffjS/rOwHTjFI5IAKzAsgJGJqgd7capR8LjvbyfxQFlNA/CUZLXAk6m6mZUs5T IajZ3vP/dE5UfLO5uaT/AEwv/xlJkrtqCMdE9wFRFJfKHITFvhWOAOqSfoLp4FQJK3vF dglPoPVqqP4Q6r3SodyeGl/W0cLAJbvOt2LvSpFrOA16IH2fWLgBKc2xIt/R0o8LytAM DOjX9MY5l8M6Q3lmNg5SqZ+28Oi3zqspVz5kiFhBXL51sVhomBnLCUXW+ER7GVmxbbyr n8Vw== X-Gm-Message-State: ALoCoQkn0G9lxPok+f+bfxH9//Pe4hTX54ogZ+hCCVHACqCbmY5IDED12AZAq8k2mmoFfUmUVPHE MIME-Version: 1.0 X-Received: by 10.202.64.68 with SMTP id n65mr744157oia.53.1443121842073; Thu, 24 Sep 2015 12:10:42 -0700 (PDT) Received: by 10.202.94.5 with HTTP; Thu, 24 Sep 2015 12:10:41 -0700 (PDT) Date: Thu, 24 Sep 2015 22:10:41 +0300 Message-ID: From: Arnon Warshavsky To: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Missing prefetch in non-vector rx function 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: Thu, 24 Sep 2015 19:10:43 -0000 Hi All Moving from dpdk 1.5 to 2.0 we observed a PPS performance degradation of ~30%. After chasing this one for a while we found the problem: A) Between the 2 versions rte_mbuf was increased in size from 1 to 2 cache lines. B) The standard (non-vector) rx function does not perform a prefetch for the 2nd cache line of the mbuf (I see this bug exists in 2.1 as well) and it touches it setting the next pointer to NULL. I tested it in ixgbe, but it looks like it exists in all drivers in the *_rx_recv_pkts() and *_rx_recv_scattered_pkts() functions. Once added the prefetch for the 2nd line, we were back in our previous numbers. I believe this one slipped under the radar as the vector mode is now the default. We stumbled into it because we work in non-vector mode due to a different mempool bug in 2.0 which sometimes crashes the application upon port stop. I have 2 questions 1) Could anyone tell if the regression tests are comparing performance while building DPDK with the default set of flags alone, or are multiple options examined? 2) How are issues like that being tracked and later associated to a patch? Thanks /Arnon *Arnon Warshavsky* *Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon@qwilt.com *