From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CACA2A0542; Fri, 7 Feb 2020 17:26:43 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id ADDF41C0D9; Fri, 7 Feb 2020 17:26:42 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by dpdk.org (Postfix) with ESMTP id 1AC2F1C0CA for ; Fri, 7 Feb 2020 17:26:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581092800; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wbE4vHXvlhV1jM/yVeCNtKAAMGlt211pEt/HzBrkfGI=; b=BOoG3RDtV+9k91/hi2Hg7mlRcwRGr0EPY1Q0MrG4C5v0sefnew3WkdGS6clI1daGK/2JdO Zw1QYDOZnuxpn3OanTgqFZGPwkr/dYgkatkt3Uqa3PV8U8BtlmOTgyHdo1bSQi6YveQfeR b4Tq0mH7tthvV7HqUnLZFbHNCRcSBaM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-75-zUqyz2nfNgeXOviO0V3kiA-1; Fri, 07 Feb 2020 11:26:38 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B316318A5500; Fri, 7 Feb 2020 16:26:37 +0000 (UTC) Received: from ovpn-118-75.ams2.redhat.com (unknown [10.36.118.75]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 64B0D863A5; Fri, 7 Feb 2020 16:26:36 +0000 (UTC) Message-ID: <1b4726452e8537ce7cbb7a60a821be6f04bb465f.camel@redhat.com> From: Mohammed Gamal To: Stephen Hemminger Cc: dev@dpdk.org, Stephen Hemminger Date: Fri, 07 Feb 2020 18:26:33 +0200 In-Reply-To: <20200207081204.56e36149@hermes.lan> References: <20200206105541.1186-1-mgamal@redhat.com> <20200207001038.7254-1-sthemmin@microsoft.com> <3e5e62ec4a9436920ba9ab59185b49d2957a02a2.camel@redhat.com> <20200207081204.56e36149@hermes.lan> User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: zUqyz2nfNgeXOviO0V3kiA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFT] net/netvsc: initialize link state X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" On Fri, 2020-02-07 at 08:12 -0800, Stephen Hemminger wrote: > On Fri, 07 Feb 2020 15:22:23 +0200 > Mohammed Gamal wrote: > > > On Thu, 2020-02-06 at 16:10 -0800, Stephen Hemminger wrote: > > > If application is using link state interrupt, the correct link > > > state > > > needs to be filled in when device is started. This is similar to > > > how virtio updates link information. > > > > > > Reported-by: Mohammed Gamal > > > Signed-off-by: Stephen Hemminger > > > --- > > > This version marked RFT because am in airport without access to a > > > machine to test it. > > > > > > drivers/net/netvsc/hn_ethdev.c | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/drivers/net/netvsc/hn_ethdev.c > > > b/drivers/net/netvsc/hn_ethdev.c > > > index c79f924379fe..564620748daf 100644 > > > --- a/drivers/net/netvsc/hn_ethdev.c > > > +++ b/drivers/net/netvsc/hn_ethdev.c > > > @@ -823,6 +823,10 @@ hn_dev_start(struct rte_eth_dev *dev) > > > if (error) > > > hn_rndis_set_rxfilter(hv, 0); > > > > > > + /* Initialize Link state */ > > > + if (error == 0) > > > + hn_dev_link_update(dev, 0); > > > + > > > return error; > > > } > > > > > > > I tested this and I always get the link status as UP, regardless of > > whether I start the interface on the guest in UP or DOWN state. > > Looking > > at hn_dev_link_update() code, I see that the link status depends on > > the > > NDIS status that the driver gets from the host if my understanding > > is > > correct. > > The question is whether if I use 'ip li set dev $IF_NAME down' on > > the > > guest affects the status the host sees, or would the host set the > > state > > to NDIS_MEDIA_STATE_CONNECTED of the device is physcially connected > > regardless of what the guest tries to do? > > > > Are you confused about admin state vs link state? Admin state is the > up/down state in software, and link state is the (virtual) hardware > link > status. In traditional Linux, admin state is controlled by ip link > set up/down; in DPDK the admin state is implied by whether the DPDK > device is started or stopped. The link state for hardware devices is > determined by whether the hardware link has synchronized with the > switch. > In virtual environments this is synchronized. In Linux link state > is reported as NOCARRIER (IFF_RUNNING). In DPDK it is reported in > via the link info get. > > The device visible to the kernel is the accelerated networking > (Mellanox) > device and is not related directly to the netvsc device. > > To test link up/down is not easy on Azure. You would have to use > Azure CLI > to disconnect the NIC from VM. On native Hyper-V you can test by > setting up a virtual switch with an external network device; then > unplug the network device. > > I see. Thanks for the explanation. In this case this does work as expected. Tested-by: Mohammed Gamal