From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C505EA0547; Fri, 28 May 2021 12:29:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7FEBF40151; Fri, 28 May 2021 12:29:14 +0200 (CEST) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by mails.dpdk.org (Postfix) with ESMTP id F012A40040 for ; Fri, 28 May 2021 12:29:12 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id n2so2862377wrm.0 for ; Fri, 28 May 2021 03:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Z5XuAXnvFPYvbKKJjfMBg3vNbfDayRL8Ex+O3aoahL4=; b=Y/MKDkfjem/ZsHTCXRzxMBXvdzsZW+9fABv6gZZCeKzyF9qrccGW5dEpiYt972mJ1g fBZzU6OuHhMsujdbP+IJaoTWLqur8XGUozrD7dsb46SN+gZXfN1eX2t+er8M1qDX/kzW fMDSFQWIchtkhBUw0t/Gp7kWAG7R6QKzVPoVU8N5LbPUtRSxhBWf/8n/g9193CKIRJgV AoSFbhNhYcLJM6foNUFIkXWedBQ1PvgFd0aPdyJGn57Bw+UZ3vehxsYyOXO2mB8m7+p5 yeDnL4gEsPEfI6Bk8TL7D6V2P5NqXusx4s7W0PGT1YNq8Nsjvl8rAXA5523FqhJgWDFC hbEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Z5XuAXnvFPYvbKKJjfMBg3vNbfDayRL8Ex+O3aoahL4=; b=bUkbU3pAL2E4RLpAVtq0G2t5iaGSLt/KOKONzXH+IfY26LYG+gwiWswv/gL0lLRoXv zqyHXVBlzGg1sLIcXwT5lFwEtBJbvLATuS5fhptYqJGuRIjc8C3EK34+5fUQZGOJLpRc ET3/50jAYGNVdN2yxhOOIIjJbz8ScaE+M2DzEpLN1vpAf+r+5cgHFzCJ6iwsZxegFHIl Cht/UgDyxMv9H/GlwbHR4J9fxvu1hDS4JEe1PkqgxGKGJy21QLbHAzw0QCTSTGQbzwXQ nzND9O9oo0rf8NZI2l4Qx2bPfAc1wDc0i+jQ3wflRLAQi/yIVZATfTp6ZugTFtrT6XmV U8CA== X-Gm-Message-State: AOAM5314vJZLsHD3cuS7EgbpLiYp1qhJnMDSAoheZRUmmtpiNcM5XUni qh0GGTMygEbhU5tLH1+Qjv8KJVMNEJ7vNzoO26mVkXOuwchsrA== X-Google-Smtp-Source: ABdhPJxHGMNpYe3vgCANfI4/t//bKM5UcvxnI1MLgfhOFM16pPzJRBn1ytdtq9IEKmeKVxm/HAW5mPXogi7wZhrBFKA= X-Received: by 2002:adf:cd06:: with SMTP id w6mr7802034wrm.399.1622197752325; Fri, 28 May 2021 03:29:12 -0700 (PDT) MIME-Version: 1.0 From: Fried Onions Date: Fri, 28 May 2021 18:29:00 +0800 Message-ID: To: dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: [dpdk-dev] i40e PMD Linux bonding issue with VFs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" I came across the patch for the i40e PMD that allows VF to set the MAC address even if the PF had already done so in https://mails.dpdk.org/archives/dev/2020-March/160631.html I tried backporting it to DPDK 18.11's i40e PMD and it fixes the issue of allowing the VF to set the MAC address. However, Linux bonding is still not working because the values don't seem to be updated at host level. Would appreciate it if anyone has any idea what other patches are needed for Linux bonding with VFs to work on the i40e PMD in DPDK18.11 in terms of patches to the PMD or firmware upgrades on the XL710 card? Or if Linux bonding can be supported at all with the i40e PMD with VFs? The kernel's i40e driver has the following known issue with Linux bonding with VFs (copied below https://github.com/dmarion/i40e/blob/master/README), but that seems to have been fixed with the 2.15.9 release, and the patch above seems to resolve the issue of setting the MAC address by the VF for the PMD, but looks like it's insufficient for it to work when backported to the DPDK18.11's i40e PMD. Linux bonding fails with Virtual Functions bound to an Intel(R) Ethernet Controller 700 series based device ------------------------------------------------------------------------ If you bind Virtual Functions (VFs) to an Intel(R) Ethernet Controller 700 series based device, the VF slaves may fail when they become the active slave. *If the MAC address of the VF is set by the PF (Physical Function) of the* *device, when you add a slave, or change the active-backup slave, Linux bonding* *tries to sync the backup slave's MAC address to the same MAC address as the* *active slave. Linux bonding will fail at this point. *This issue will not occur if the VF's MAC address is not set by the PF.