From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751679AbcGNQPb (ORCPT ); Thu, 14 Jul 2016 12:15:31 -0400 Received: from smtp-fw-6001.amazon.com ([52.95.48.154]:38073 "EHLO smtp-fw-6001.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751276AbcGNQP2 (ORCPT ); Thu, 14 Jul 2016 12:15:28 -0400 X-IronPort-AV: E=Sophos;i="5.28,363,1464652800"; d="scan'208";a="133569175" Date: Thu, 14 Jul 2016 09:15:11 -0700 From: Matt Wilson To: Benjamin Poirier Cc: Netanel Belgazal , David Miller , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, zorik@annapurnalabs.com, saeed@annapurnalabs.com, alex@annapurnalabs.com, aliguori@amazon.com, ben@decadent.org.uk, romieu@fr.zoreil.com, rami.rosen@intel.com, antoine.tenart@free-electrons.com, "John W. Linville" Subject: Re: [PATCH net-next V3] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA) Message-ID: <20160714161511.GA30697@u54ee753d2d1854bda401.ant.amazon.com> References: <1468478774-19942-1-git-send-email-netanel@annapurnalabs.com> <20160714152215.GA24590@u54ee753d2d1854bda401.ant.amazon.com> <20160714160803.egrmos7soc6qvrry@f1.synalogic.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160714160803.egrmos7soc6qvrry@f1.synalogic.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 14, 2016 at 09:08:03AM -0700, Benjamin Poirier wrote: > On 2016/07/14 08:22, Matt Wilson wrote: > [...] > > > > Dave and Benjamin, > > > > Do you want to see the interrupt moderation extensions to ethtool and > > the sysfs nodes removed before this lands in net-next? Or should > > Netanel remove the sysfs bits until we can extend the ethtool > > interfaces to cover the parameters that ena uses? > > I couldn't say what's acceptable or not. A few other drivers (qlcnic, > sfc, ...) already have sysfs tunables. Maybe John, as the new ethtool > maintainer, can weight in too about the changes required to ethtool. We definitely want ethtool to handle all the settings, it's just a question of when. We also want to address and resolve all the great feedback so far, and since you originally raised the point about extending ethtool I wanted to see if you have any major objection. --msw