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.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED 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 D876AC282C3 for ; Thu, 24 Jan 2019 09:43:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 99B3820855 for ; Thu, 24 Jan 2019 09:43:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="MWpodX7J" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726036AbfAXJnM (ORCPT ); Thu, 24 Jan 2019 04:43:12 -0500 Received: from mail-qt1-f196.google.com ([209.85.160.196]:35999 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725939AbfAXJnM (ORCPT ); Thu, 24 Jan 2019 04:43:12 -0500 Received: by mail-qt1-f196.google.com with SMTP id t13so5740145qtn.3 for ; Thu, 24 Jan 2019 01:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MqKp/YRZ37VvRRcUmkF/LqUCUCJAP41MoeCgVJ249Yo=; b=MWpodX7JcUjG9rQNcRl8FVvPti4CN7PGZ/JBsD8E43bvambMVmNh8PQHhasLK4kJkJ mMNk4Vmj6FItUlNRiP20myl/Yx2FKF77tNAJaupuWyzkE/hjrwM0oH7QTkFsIvjF+/nE GVpxwobRaXCSSgRby8NZ1PgJ4WGCoiJmgZ/mE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MqKp/YRZ37VvRRcUmkF/LqUCUCJAP41MoeCgVJ249Yo=; b=ODHPLgXryBgzBhLYwi4CX3SAZt+gCb0dyqaF1ObpjDfn0Wx6Kk7y2RCf3X1x5ugd2R /Fc9QuEdNf5A4IRher3aAlMr7H0kXBD4hPxV02Jk94ORPjETDnH11BVkGAMlrKYAvJ02 f0V1MlIzDrgG+oB/ZSEXu0UDLJHs/v2yr0J7/hRuk8YIR8EJPBwBU5zgPMGzVzzgs4mh vXxbgGPowgPJTLyf0aiemORwQjAhoBmR9SWnVluGkcRiBSei3o8uRq/yWNCgHXeBqIA+ eqijTUrLOc76o5s7W9QvRIKzbzat4ZkoKPMZiW6kCwNLEZlo2XWtL5++N1aNBO1g55Qb cdiQ== X-Gm-Message-State: AJcUukcsKsbRO3u7HXfdhFVS3WRSgHtt0ZBJn28NMVQJ/mleUWFSjzWq 410wS8BqmOJBCig8z6L3Z/k7JYIY7yrmyejxADW+mg== X-Google-Smtp-Source: ALg8bN41LDM5yDo4h8f0s7sNNOODv6QKyu0vFdIxri0l4ynioxRVqNJrDfKiu5AvMC8s958q9DVWAm2b1++JfqYgiUA= X-Received: by 2002:a0c:b786:: with SMTP id l6mr5371177qve.244.1548322990773; Thu, 24 Jan 2019 01:43:10 -0800 (PST) MIME-Version: 1.0 References: <1547795385-12354-1-git-send-email-vasundhara-v.volam@broadcom.com> <20190118143319.GG26670@unicorn.suse.cz> In-Reply-To: <20190118143319.GG26670@unicorn.suse.cz> From: Vasundhara Volam Date: Thu, 24 Jan 2019 15:12:59 +0530 Message-ID: Subject: Re: [PATCH net-next v7 0/8] devlink: Add configuration parameters support for devlink_port To: Michal Kubecek Cc: Netdev , David Miller , "michael.chan@broadcom.com" , Jiri Pirko , Jakub Kicinski Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jan 18, 2019 at 8:03 PM Michal Kubecek wrote: > > 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.) Agreed. This can be extended in future for other types of WoL. > > > 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. This already supports as persistent or runtime WoL. All devlink parameters have this option to be either persistent or runtime which is defined by the driver when defining the parameter. > > > 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). Devlink supports both persistent and runtime WoL setting. It depends on driver's use case. > > Michal Kubecek