From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 29EF2231E for ; Thu, 30 Aug 2018 00:12:41 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id q8-v6so7024988wmq.4 for ; Wed, 29 Aug 2018 15:12:41 -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=2R5JOt7M/ZkRVjF2hJr3bFNQN05k1wsLX5LsgXRj5QQ=; b=oshX4SsneoGs4u9aJVGu+1dkk7Ti+7veB4QH1l2zpe9p2SZ6P8tLt5i2h+/wiv1ax4 gRa4c0goAVKfcSU80ETAt3CgWw2ozHY6bpwlH8pfIJCqMnFl4uS9Ii8Bj4xfoQDB2pNf U0heN+2YobhcdzfDZ87aH2x++VIKtJcIHrm52OftJJObKSc3IRyJS6ZZbWgKQ3W/6IDy ohydiewyjE/J+PsWSbeXO5yksk6RkCVtBguKNCiVsNu5PBiqeGZVwGQVfxcVFg7Hjtaj 62h0l8tisHBW5jsYVFbK7z9TRGRARk8VuH5E6IC61hTBc96mLzQNQvw8z3fTxR5L6l61 nw6w== 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=2R5JOt7M/ZkRVjF2hJr3bFNQN05k1wsLX5LsgXRj5QQ=; b=HT9houakMu7nsxtw0GarOigeDtojuezuD/dg4dc8WSVn/F/DpPXPK4TLXnKZfGUeSy m0Z5R70YRFs+KQW+xKr1NDXww4v1cJA9SfnEpcIcCK9l2BrCy1nq2kpiEFcx5HZrMiXV iJZzLDLkbdecYca4KvAzx3NkBhl3Z5QR6CS8Ej8GPGj/+SkJsnNPfR2th/ycQh+VxyK9 tVTTuAM/Ax4lEZFpgQyl6OmHYsYWCo27wJFCRFkjwO1ZFG3gXAHXbMN9KfiRXLK0z4oj h1KsjxZYrW4s0hWTtVhnUeM7nP7TXSNWOxlmblMae/89XAe6MTptMmKvY2OBh6257i5v o2oA== X-Gm-Message-State: APzg51CFYruLv3bp1LpjBd+kLWK9mId7A2auH/sutChzkfiRJqoJUSzP NK15a1Lhn+V6p8BChkkdYmxEEOQJORNsTpUoyIk= X-Google-Smtp-Source: ANB0VdbhTBuwvl5JyX64mQ6o1iraTJzk9t8LpfXt8DM3QWJ9299nvqjTJUzZTgGl8N898HXS2OANVqx1DDHm0QI9EWk= X-Received: by 2002:a1c:7301:: with SMTP id d1-v6mr2912wmb.34.1535580760592; Wed, 29 Aug 2018 15:12:40 -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 15:12:00 -0700 (PDT) In-Reply-To: <20180829150014.0ae59128@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> <20180829150014.0ae59128@xeon-e3> From: Dan Gora Date: Wed, 29 Aug 2018 19:12:00 -0300 X-Google-Sender-Auth: o156EkifHV94jzCiXPLhM6cQB2A 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 22:12:41 -0000 On Wed, Aug 29, 2018 at 7:00 PM, Stephen Hemminger 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 is a stable API on Linux. Ok, I didn't know this... Still it seems better to me to be able to call rte_kni_update_link(kni, link); than 'open ("/sys/whatever/where ever it may be this kernel version/link/"); write(fd, "1"); close(fd); or whatever... But I guess if it is actually a stable API, we can hide all of that in 'rte_kni_update_link() and just do away with the ioctl! I'm actually kind of shocked that I'm the only one who has run into this.. I would have thought that having an accurate link status would have been important for whoever used KNI. > >> 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... > > The device model on BSD is significantly different than Linux. > Doing KNI on BSD is going to be a full rewrite of the driver anyway; > I won't worry about sysfs, dependency. > > The important part is that if KNI is ever going to be supportable > it needs to be upstream in Linux, not a bolt on out of tree driver. > Most Enterprise distributions will not support out of tree drivers > for good reasons. Agreed there.. I was really torn between using KNI or the TAP interface. KNI seems cleaner, and at least at the time that I started working on this, seemed like the way to interface to the kernel moving forward. The TAP interface stuff didn't seem like it was necessarily going to be supported moving forward and the KNI was supposed to be the "high performance" method to interface to the kernel. But having to build and install the rte_kni module on every system that we install our software on is a major pain. d