From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by dpdk.org (Postfix) with ESMTP id 92A7A5A83 for ; Thu, 5 Mar 2015 08:33:54 +0100 (CET) Received: by igbhl2 with SMTP id hl2so43550013igb.3 for ; Wed, 04 Mar 2015 23:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nyY11JKK428lnh0VYeN+0GfwxZL2+KHxexO6zaALwSM=; b=JNzb1gEHf/GXy3zkBpvKpySXSEpXXEaw+z4kogCvn/4HFKsuPZ9Qa7gmFSb43/wno2 cVVjVPU9SWvGALIyAO9ZjuVG2h59O0m65McQTTbXWyVSl+adX9ADS3I8cbyIUDtSD1Js 6iVW4C2l3F70FFpbXUqEEdnNfObC2lwPEUqQCEX+YHOVmESPopGrjNjg1YW7rprF8PsW c6TfgxFPZT2w54yrv8W90eD7r99saEV+x0QXRs97fqXFQHY/rEEPmJqlalyPd81GWno7 WhNPW7ocXLeoG8xmZ5+LSXuwSvz7aUQml4BnG2fFV9sne+EdSUs44OYWhxyov67rG9fu NWgw== MIME-Version: 1.0 X-Received: by 10.50.7.1 with SMTP id f1mr18135916iga.8.1425540834042; Wed, 04 Mar 2015 23:33:54 -0800 (PST) Received: by 10.36.24.198 with HTTP; Wed, 4 Mar 2015 23:33:53 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Mar 2015 23:33:53 -0800 Message-ID: From: "JP M." To: "Zhang, Helin" Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] KNI with multiple kthreads per port 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, 05 Mar 2015 07:33:54 -0000 On Wed, Mar 4, 2015 at 9:40 PM, Zhang, Helin wrote: >> * 32-bit (yes, KNI works fine, after a few tweaks hugepage init strategy) > Interesting! How did you get it works? In a nutshell: The current (circa r1.8.0) approach does mmap starting from the bottom of the address space, then does a second round of mmap, then unmaps the first round. Result is (AFAICT) unnecessarily wasting much of the address space. I'll try to get my patch cleaned up and posted in the next several days. > What do you mean "vEth0_1 cannot be configured"? The primary KNI device, vEth0_0, has (I forget which) ops defined, but any secndary KNI devices do not. That said, I now see that once the latter are brought up, I can set their MAC address. Which turns out to be important. (see below) >> Should I be bonding vEth0_0 and vEth0_1? Because I tried doing so (via sysfs); >> however, attempts to add either as slaves to bond0 were ignored. > > What do you mean bonding here? Basically KNI has no relationship to bonding. All the same, I figured out what I was doing wrong (user-error on my part, I think) with regards to bonding (EtherChannel) and am now able to get multiple vnics to enslave. The catch was that the secondary KNI devices, after being enslaved, are assigned a random MAC. After doing so, it is necessary to then manually set their MAC to that of the primary KNI device. Thereafter, Rx/Tx are load-balanced as expected. That assignment of a random MAC to the secondary KNI devices is the hang-up; not clear whether there's a deliberate reason for that happening. ~jp