From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id 498BE231E for ; Wed, 29 Aug 2018 23:02:47 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id v16-v6so6065542wro.11 for ; Wed, 29 Aug 2018 14:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Q+66Ab+1/YY+/Qqj3ueHul0exQ/0mo6jeAKaiPTQ1X0=; b=oS9DbuG7gfbGpGFydIaMl6GCKOD5Zlaqwf8MTRiI7Ajfv2IE9+YbkHcAsTIpX2BYS5 G5lAzPXbz6oQ4zTj2DPlB+Ym1377H/u75Y7nPWeTFWsEUsOV+QH2G76KeOcFO5j8OwEX qCV6a175cAIfgLjV46gcvzWNDYF7qz6l1KQNr1bMSuL4waHd0flsVlRpfl50gr6n6U+k RGTQLex+1yIJZf2rkzHChGNpKIOuJ+DIsVP6wusyWmO72xA2GuvjL+2FzK4nxuYwGN7Y 3/FzCiPsPrF/C3phe5ozk1cSMWL/KX9jdJZmkg5FEUFaOgJZmxhPKB/TvT2Mk6nFvKOr nR5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Q+66Ab+1/YY+/Qqj3ueHul0exQ/0mo6jeAKaiPTQ1X0=; b=LHzyoATarGUet7yqYN0kuqL7JOtrNJ30n4tYiLZOEs8MgqfZAEwGCIiqb2HfOo3TSY yd8+ZL//tXlxKyg2Pb2a1oeW+r4hKrUaiFjXK2hivfX2gG7C11qvQ1FePVBFhZFAHkzk pRDSQwe8kHyf0pGR99TptIJwR0ZHdCT0ORSs2VyJrqbySDoO2cYStFYVYXJSFiuRq3+W BMhua4eqNm/ZqSNze30xSo7GJhMCs/MvbN0xEM1WJSKSs+Jxs4I+UzIdCo+ysG7GHkRa KNkxltEQPeBwIAdxWrLL4JwbzfKaFGd6DEuaAqnXw3HD5KXaMNUoIicdnFM7w3XcBzL+ VC5A== X-Gm-Message-State: APzg51CHsXr+vz9mIhY3KvkNZb08Hw1wlXvGkpmSeeYRsswUaORUl+NV ZWx+ilQ/ZyhLSEF+z2TnMtKNqxBO07GZQq1oYag= X-Google-Smtp-Source: ANB0VdaolNwnehPCIZoc0jn67G9A2Y5pOc7UdI3DVweTRo4t6D2ubrZ/bHFYUPLUkgDuQyG65iUcldeRaTMLetK8Srw= X-Received: by 2002:adf:f687:: with SMTP id v7-v6mr5488395wrp.201.1535576566586; Wed, 29 Aug 2018 14:02:46 -0700 (PDT) MIME-Version: 1.0 Sender: dan.gora@gmail.com Received: by 2002:adf:fbc1:0:0:0:0:0 with HTTP; Wed, 29 Aug 2018 14:02:06 -0700 (PDT) In-Reply-To: <20180829085410.4411c07e@xeon-e3> References: <20180628224513.18391-1-dg@adax.com> <20180629015508.26599-1-dg@adax.com> <20180629015508.26599-11-dg@adax.com> <20180829085410.4411c07e@xeon-e3> From: Dan Gora Date: Wed, 29 Aug 2018 18:02:06 -0300 X-Google-Sender-Auth: TreyDL389aPvSlrmcwJ60INxu6k Message-ID: To: Stephen Hemminger Cc: Ferruh Yigit , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 10/10] kni: add API to set link status on kernel interface 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: , X-List-Received-Date: Wed, 29 Aug 2018 21:02:47 -0000 On Wed, Aug 29, 2018 at 12:54 PM, Stephen Hemminger wrote: > On Thu, 28 Jun 2018 18:55:08 -0700 > Dan Gora wrote: > >> Add a new API function to KNI, rte_kni_update_link() to allow DPDK >> applications to update the link state for the KNI network interfaces >> in the linux kernel. >> >> Note that the default carrier state is set to off when the interface >> is opened. >> >> Signed-off-by: Dan Gora > > Do you really need a special ioctl for this? > There is already ability to set link state via sysfs or netlink. I think yes.. AFAIK sysfs does not constitute a stable API; it's only available for Linux (yes, I know KNI is linux-only currently, but there's not really any technical reason why it can't work on BSD) and there are already callbacks to change the MTU and MAC addresses which could also be done via netlink. IMHO having the kernel have an accurate view of the link state is more important than the ability to change the MAC address of the interface... In our application we want the linux kernel/"normal" userspace to be able to use the DPDK controlled interfaces like any other interface. We need to be able to assign IP addresses to them, have them participate in routing, etc. Since they are controlled via our DPDK application, there is no way for the kernel to know when the cable is connected/removed since that information is only communicated to the DPDK application. The other option, which I toyed with but decided against, would be to have a polling thread in the KNI module to call a callback into the DPDK application to poll the link status. However that would still possibly leave a time period when the link is down, but the kernel does not know about it. I decided that it would probably be best to just have a way for the DPDK application to inform the linux kernel (via the KNI module) that the link was down. It's important for the linux kernel to know about the link status if the interface is going to be treated like any other. Things like assigning IP addresses and adding the interfaces to the routing table happen automatically when the link is marked "up". If the link is not marked "up", or is "up" when it should be "down", then the kernel cannot configure that interface correctly, or will use it when it should not be. thanks dan