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 341EBA00BE for ; Tue, 19 Apr 2022 11:34:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2FC0642837; Tue, 19 Apr 2022 11:33:57 +0200 (CEST) Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by mails.dpdk.org (Postfix) with ESMTP id D67924068E for ; Wed, 13 Apr 2022 20:41:41 +0200 (CEST) Received: by mail-ej1-f44.google.com with SMTP id s18so5862568ejr.0 for ; Wed, 13 Apr 2022 11:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VFVw21IH0Mgfrq63IFnrtrDImc+DSJeu/t7b7EIXFTc=; b=JNsz2v7Ava+/beQaFyjjWNy6O0yahVE63hoV37fory2TwHE27rok4xpmTfk9qzeBlD 4V+Em//mycC+v/k03zfp9taCnvE7+q6z0muAr+z0PvL7JztXCrAtLaJlQ4smG+rCxotj R8kKl2O8FNBrBQWfZrv3LSr1X8l11iQFHsNba44X3fPS6QOpBSr2t1fr9yXAs38fzGXY nO1uVmRxifJKvjKJdoBKc3fwuBEkDRMcRnTCbC3vsEChub2BEE/B4UcEGj9CvPYXlK7G l5fphbo3FtWdHTgQT2N2jJ0UcsEkoh4XwsyWOyOBMXQ2yZMZHoZrGJcocPcUfnkwXJeB 5qlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VFVw21IH0Mgfrq63IFnrtrDImc+DSJeu/t7b7EIXFTc=; b=GiIWt6ehNd9sfnDAR/vE488JRTP1JP4arEsKu+UP9bxyHUhOOwnw62pI39s4fNn7WJ RLeT5BIQczgjzGEN5+Cct+D/9xSgybqbaLJYV4fA1pD3piGOxRvlIpbMLdvpGR4dWLtB AdIHGi0dS+xFvFg33iPB1BVuiEg5yZn07PdBpdfUPrgS98GBN+K+8tMzBlN/2COWwmI7 BgugyKobJaFDYJpaPioRcFz21nsBdEl8X8/YphfhYFeocv9qtPHYE84kxzJScBFYK+4e XfwTwgKpvVjVFAfl0VBBcQqNbdg562gdGD0oFUSZFPyieFAmfAdCA58yQjvvCEzSfMR1 4SMg== X-Gm-Message-State: AOAM530hCLGIrw7lchJf6qQSq819pg+eAQMsMKdQjpkHFnx49QUl3QHU Dd5h43iO3ndRwaKI1RFExPajM8tYjgpUeCYty/TDUnoW X-Google-Smtp-Source: ABdhPJxNIWhKgf4alJEOcuzk7qfv7a0dIisrorLPvS9U+Fa3bt7jVMQ4RbmNtyDB1KC88pbvtsDssDs7KEZ4vPyr7h8= X-Received: by 2002:a17:906:c344:b0:6b4:c768:4a9a with SMTP id ci4-20020a170906c34400b006b4c7684a9amr40572630ejb.151.1649875301238; Wed, 13 Apr 2022 11:41:41 -0700 (PDT) MIME-Version: 1.0 References: <20220413085802.7506b1f8@hermes.local> In-Reply-To: <20220413085802.7506b1f8@hermes.local> From: Yang Luan Date: Wed, 13 Apr 2022 11:41:30 -0700 Message-ID: Subject: Re: running DPDK application on Azure To: stephen@networkplumber.org Cc: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000410f7605dc8d87b4" X-Mailman-Approved-At: Tue, 19 Apr 2022 11:33:56 +0200 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 --000000000000410f7605dc8d87b4 Content-Type: text/plain; charset="UTF-8" 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. > --000000000000410f7605dc8d87b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Stephen.

Is the Netvsc PMD selec= ted 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 exactl= y Azure selects which NIC to receive a given packet?

Yang

On Wed, Apr 13, 2022 at 8:58 AM Stephen Hemminger <stephen@networkplumber.org> w= rote:
On Tue, 12= Apr 2022 13:09:51 -0700
Yang Luan <lua= n.penny@gmail.com> wrote:

> Hi,
>
> We have an application using DPDK on AWS and would like to port it to<= br> > 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 Net= vsc
> 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.<= br>
>
> 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 re= ceive
> all the packets. We run a proprietary UDP based protocol on top of DPD= K.
> Are all UDP packets guaranteed to be received by the mlx NIC?

That won't work. the MLX device only sees established flows.
--000000000000410f7605dc8d87b4--