From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F14D7C43387 for ; Fri, 18 Jan 2019 14:33:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C94CD2086D for ; Fri, 18 Jan 2019 14:33:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727463AbfAROdV (ORCPT ); Fri, 18 Jan 2019 09:33:21 -0500 Received: from mx2.suse.de ([195.135.220.15]:52688 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727177AbfAROdV (ORCPT ); Fri, 18 Jan 2019 09:33:21 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 33D7CAEC3; Fri, 18 Jan 2019 14:33:20 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id 6FFD5E00A1; Fri, 18 Jan 2019 15:33:19 +0100 (CET) Date: Fri, 18 Jan 2019 15:33:19 +0100 From: Michal Kubecek To: netdev@vger.kernel.org Cc: Vasundhara Volam , davem@davemloft.net, michael.chan@broadcom.com, jiri@mellanox.com, jakub.kicinski@netronome.com Subject: Re: [PATCH net-next v7 0/8] devlink: Add configuration parameters support for devlink_port Message-ID: <20190118143319.GG26670@unicorn.suse.cz> References: <1547795385-12354-1-git-send-email-vasundhara-v.volam@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1547795385-12354-1-git-send-email-vasundhara-v.volam@broadcom.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jan 18, 2019 at 12:39:37PM +0530, Vasundhara Volam wrote: > There is difference of opinion on adding WOL parameter to devlink, between > Jakub Kicinski and Michael Chan. > > Quote from Jakud Kicinski: > ******** > As explained previously I think it's a very bad idea to add existing > configuration options to devlink, just because devlink has the ability > to persist the setting in NVM. Especially that for WoL you have to get > the link up so you potentially have all link config stuff as well. And > that n-tuple filters are one of the WoL options, meaning we'd need the > ability to persist n-tuple filters via devlink. > > The effort would be far better spent helping with migrating ethtool to > netlink, and allowing persisting there. > > I have not heard any reason why devlink is a better fit. I can imagine > you're just doing it here because it's less effort for you since > ethtool is not yet migrated. > ******** > > Quote from Michael Chan: > ******** > The devlink's WoL parameter is a persistent WoL parameter stored in the > NIC's NVRAM. It is different from ethtool's WoL parameter in a number of > ways. ethtool WoL is not persistent over AC power cycle and is considered > OS-present WoL. As such, ethtool WoL can use a more sophisticated pattern > including n-tuple with IP address in addition to the more basic types > (e.g. magic packet). Whereas OS-absent power up WoL should only include > magic packet and other simple types. If I understand correctly, it's that way now. I'm not sure there is a technical reason preventing more complex WoL types in the OS-absent case in the future. Also, even with traditional ethtool WoL setting, most NICs only support some of the types (I'm not sure if there is a NIC which would support all of them.) > The devlink WoL setting does not have to match the ethtool WoL > setting. IMHO this is not really a problem. We can either use an additional flag telling kernel/driver if we are setting runtime or persistent WoL mask or we can pass (up to) two bitmaps. > The card will autoneg up to the speed supported by Vaux so no special > devlink link setting is needed. > ******** Like Jakub, I'm not convinced there is a strong technical reason to have each of the WoL settings handled through a different interface. I don't say, though, that ethtool is necessarily the right one. If there is a consensus that it better fits into devlink, I can imagine that both could be accessible through devlink (for start, in drivers which choose so, e.g. because they want to implement the persistent setting). Michal Kubecek