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 9E90CA050A for ; Thu, 14 Apr 2022 01:36:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2C33140689; Thu, 14 Apr 2022 01:36:24 +0200 (CEST) Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by mails.dpdk.org (Postfix) with ESMTP id 9F80940687 for ; Thu, 14 Apr 2022 01:36:23 +0200 (CEST) Received: by mail-pg1-f174.google.com with SMTP id t13so3203666pgn.8 for ; Wed, 13 Apr 2022 16:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=18YHE+T86WQXCU8Fz8qQkJNBk1fTfzIWbFrESGeufSk=; b=V5ODBs11sF5MWmsjspHAjiJvAOi+wxd4t7M+q6WLjWcvkQJOmjFUXIb89LfOGNgacO X/kRgXEfvS6mwOGKuWqZta8H3DD4GG1MmuAla6c+/UnKgwAfx5me5NSkJOz5d17f4vbJ xhTgUQTI9o8OaLhos6D8cOn8Dhqlvfe6ZAYxob4RLXIxZRFbWVwJsgkoL3kvG4q+maZm s/F7QAVzmqeytvt2+MLHzzgr9jUomqD9otIfhXXRGQFyd/iKqZ8oHg9IWaiNsrsxu0kk Ggf+xeVhcGPwLEbJCwMsaTGDPX6+mqu7ZdNiZGiTdJfUf/v2v0FMY4I9ESerI7h3w1x1 l/kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=18YHE+T86WQXCU8Fz8qQkJNBk1fTfzIWbFrESGeufSk=; b=GO74JapACNOb3sYCzdK8FF4AQvkjdMVMjR9pZtE5ZDTRIxF4/5gk35b5xuCHSyRPg8 nJcyuyxqpUmG4VP7IDgdI5NZAgUpTXgUDrmi+U2Kq6Wm73/vgOcx9DuM4ONVSGtvREKK tOxy7KjY9RMMWRwZ0w0xEnKcz7cmgrGkKEUtoXK6kPZislBSRbKw6wxd5hvxDKT1Wu8l 7OOg86xDeHZU+mS2QZsO6/G8W5ZswpkfPrfE5OqfsZEUh2KCm33YfQPVklro0yWvnf6A HnwHQxvY7F6bvvPP6hLMEAIcOSiQN/cnhdYbWvFZV71cEw2F9wagzd5LA9T7g9Y5Ps/E SLyQ== X-Gm-Message-State: AOAM5337u9iZK/l4aRXlceZ8IOjzxig+aBgw6dtl8d+mxlDs2/E4ii+z d+S1lP1PFjHOIZTpNyIUyVbhjw== X-Google-Smtp-Source: ABdhPJz5OrH89K7lGSZ/4cRucPoTxH0azqZXo4KHxm066Oh9poYxA0YbW5J7ak5HQ/s00nPfgIa/eQ== X-Received: by 2002:a63:6a04:0:b0:398:6e02:60d4 with SMTP id f4-20020a636a04000000b003986e0260d4mr36889357pgc.509.1649892982620; Wed, 13 Apr 2022 16:36:22 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id i13-20020a17090a2acd00b001cd498dc153sm134149pjg.3.2022.04.13.16.36.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Apr 2022 16:36:22 -0700 (PDT) Date: Wed, 13 Apr 2022 16:36:19 -0700 From: Stephen Hemminger To: Yang Luan Cc: users@dpdk.org Subject: Re: running DPDK application on Azure Message-ID: <20220413163619.546655de@hermes.local> In-Reply-To: References: <20220413085802.7506b1f8@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On Wed, 13 Apr 2022 11:41:30 -0700 Yang Luan wrote: > Thanks Stephen. > > Is the Netvsc PMD selected by default or I'll need to specify it somewhere? > > Since I'm running a proprietary UDP protocol, 3rd parties (e.g. Azure) > won't know how a flow is established. I'm curious how exactly Azure selects > which NIC to receive a given packet? > > Yang > > On Wed, Apr 13, 2022 at 8:58 AM Stephen Hemminger < > stephen@networkplumber.org> wrote: > > > On Tue, 12 Apr 2022 13:09:51 -0700 > > Yang Luan wrote: > > > > > Hi, > > > > > > We have an application using DPDK on AWS and would like to port it to > > > Azure. What would be recommended PMD to use? If I understand correctly, > > we > > > can either use the Netvsc PMD or the vdev_Netvsc PMD. It seems the Netvsc > > > PMD is newer. > > > > Short answer: > > > > Netvsc PMD is faster and can handle events better. > > vdev_netvsc/failsafe/tap is slower but can emulate some types of rte_flow. > > > > > > > > An alternative is to use the mlx4 PMD by only attaching to the mlx NIC's > > > PCI address. As I understand it, the concern is the mlx nic may not > > receive > > > all the packets. We run a proprietary UDP based protocol on top of DPDK. > > > Are all UDP packets guaranteed to be received by the mlx NIC? > > > > That won't work. the MLX device only sees established flows. > > The choice is made based on whether vmbus is unbound from kernel or not. If vmbus is left bound to kernel, then hv_netvsc will look at all the network devices, and those without any routes it will setup. The setup makes the TAP/failsafe sub devices. If vmbus device is unbound from network device and instead bound to hv_uio_generic, then the DPDK startup code will see it and should setup from there. The documentation is there in many places.