From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by dpdk.org (Postfix) with ESMTP id 8D6935A50 for ; Fri, 5 Jun 2015 17:27:21 +0200 (CEST) Received: by wiam3 with SMTP id m3so22950802wia.1 for ; Fri, 05 Jun 2015 08:27:21 -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=rh+EX6Do+zz2T5/Sel8HzoDat6ZOmkTUV5V8rswwfhE=; b=fgl0bWMaFwSo0SRblMyjt09746cfW+vFXM/qLq1bW+3sFf6prkGMydc5kEUoJNn9pU Z33hcyL+X32LbzN5r9H5pRtjxKDdHNA9CNyeND1ecrVboc9TKPPj4az0mpqnb6T4kHyN w1MXrC9hZMpVnwnh/kMwhGZwV9cFiRwQFqdfKDZ1VIDwiWnn4Gj6MCC4Xqs094rNhrvC nTLRL4kqXU08VbYyF2iv3S+KFJgLOUfIpnCyvWsussqh5jrQ3c1fjPoBR4U1J+DfNmq/ f6Jk2sh8etDkOOoxw27ARsnUm5ymwf0CZ8Nnf0tmNuMMDw1Sxzh2rhVOssrlYIU0p3MB Hd4g== X-Gm-Message-State: ALoCoQmxUxr+SW7VWraiDOxtUpzpNlPsomlVvRIaNq1XwuVWnRNS0cVDi4ZKjGdV5thw6+bu+7tT MIME-Version: 1.0 X-Received: by 10.194.120.106 with SMTP id lb10mr7602829wjb.54.1433518041451; Fri, 05 Jun 2015 08:27:21 -0700 (PDT) Received: by 10.194.36.193 with HTTP; Fri, 5 Jun 2015 08:27:21 -0700 (PDT) Date: Fri, 5 Jun 2015 10:27:21 -0500 Message-ID: From: Jay Rolette To: DPDK Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] More KNI performance 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: Fri, 05 Jun 2015 15:27:21 -0000 Follow-up to my long email about KNI performance so we don't have chapter-length quotes in any discussion... Increasing HZ to 1000 helped, but I'd really like a way to wake the KNI kernel thread up on demand. I'm hoping someone with more Linux kernel experience than I have might have some ideas. Is there some mechanism available that the KNI kernel thread could sleep periodically, but somehow be awoken from user space? Basically looking for something to simulate the HW interrupt that network drivers normally rely on. When KNI packet rates are relatively low, that 1-4 ms latency from the KNI kernel thread sleeping becomes painfully obvious. If my DPDK app knows that KNI traffic is light, it would be nice to "kick" the KNI kernel thread to get to work. So far it looks like adding a syscall is about the only path to let a user-space app kick a kernel thread. I haven't gotten as far as figuring out the details to make sure this all works in practice. Any suggestions or guidance here would be welcome. Thanks, Jay