All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Nelson, Shannon" <shannon.nelson@intel.com>
Cc: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"e1000-devel@lists.sourceforge.net"
	<e1000-devel@lists.sourceforge.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
	"gospo@redhat.com" <gospo@redhat.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"sassmann@redhat.com" <sassmann@redhat.com>
Subject: Re: [E1000-devel] [net-next v4 7/8] i40e: sysfs and debugfs interfaces
Date: Thu, 5 Sep 2013 11:32:59 -0700	[thread overview]
Message-ID: <20130905113259.55ad2ad2@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <FC41C24E35F18A40888AACA1A36F3E416C6249AD@FMSMSX102.amr.corp.intel.com>

On Thu, 5 Sep 2013 17:53:38 +0000
"Nelson, Shannon" <shannon.nelson@intel.com> wrote:

> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Wednesday, September 04, 2013 5:38 PM
> 
> [...]
> 
> > Also, anything in sysfs is device specific and you really need to make
> > a strong case for why your device is special and needs an exception.
> > Other devices will have hardware switches and doing something through
> > sysfs is going to create a pain for any controller application.
> > 
> > I vote against including the sysfs VEB stuff because it will become
> > a lifetime ABI.
> 
> If we simply remove the VEB attributes (cvlan, mode, seid, svlan) but keep the model structure and the VSI attributes, will that satisfy your vote, or are you suggesting that we should drop the whole sysfs model that we implemented?
> 
> At this point after some discussion internally, we think it would be better to simply remove the whole sysfs module - it is an optional section with no direct operational requirement.  The intent was to get something started that looked useful, but perhaps we were a little premature in presenting this model for these new switch offload capabilities.
> 
> As Dave rightly pointed out, we may want to bring this back in the future, but I think that we have more work to do with the community in proposing and designing a switching model, if it really is even needed.  That's not an over-night thing, and we shouldn't be trying to patch up something that has fundamental concerns.  Also, bringing it back later when it isn't obscured by the rest of the driver might be more successful in getting community input.
> 
> sln
> 
> 

IMHO  attributes are a nice way of handling the VSI attributes since they
seem hardware specific.  Not sure how to do the right thing with switching.
Should it look like Macvlan, bridge, VXLAN, or something else.

  reply	other threads:[~2013-09-05 18:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-04 23:17 [net-next v4 0/8][pull request] Intel Wired LAN Driver Updates Jeff Kirsher
2013-09-04 23:17 ` [net-next v4 1/7] i40e: main driver core Jeff Kirsher
2013-09-05 16:26   ` Stephen Hemminger
2013-09-05 17:59     ` Nelson, Shannon
2013-09-04 23:17 ` [net-next v4 2/8] i40e: transmit, receive, and napi Jeff Kirsher
2013-09-04 23:17 ` [net-next v4 3/8] i40e: driver ethtool core Jeff Kirsher
2013-09-04 23:17 ` [net-next v4 4/8] i40e: driver core headers Jeff Kirsher
2013-09-04 23:17 ` [net-next v4 5/8] i40e: implement virtual device interface Jeff Kirsher
2013-09-04 23:17 ` [net-next v4 6/8] i40e: init code and hardware support Jeff Kirsher
2013-09-04 23:17 ` [net-next v4 7/8] i40e: sysfs and debugfs interfaces Jeff Kirsher
2013-09-05  0:37   ` [E1000-devel] " Stephen Hemminger
2013-09-05  1:25     ` Nelson, Shannon
2013-09-05  3:19       ` David Miller
2013-09-05  4:08         ` Brandeburg, Jesse
2013-09-05  4:37           ` David Miller
2013-09-06  3:09             ` Nelson, Shannon
2013-09-05  4:55       ` Stephen Hemminger
2013-09-05 11:10         ` Bjørn Mork
2013-09-05 15:21           ` Stephen Hemminger
2013-09-05 17:53     ` Nelson, Shannon
2013-09-05 18:32       ` Stephen Hemminger [this message]
2013-09-05 23:38         ` [E1000-devel] " John Fastabend
2013-09-04 23:17 ` [net-next v4 8/8] i40e: include i40e in kernel proper Jeff Kirsher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130905113259.55ad2ad2@nehalam.linuxnetplumber.net \
    --to=stephen@networkplumber.org \
    --cc=davem@davemloft.net \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=gospo@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=sassmann@redhat.com \
    --cc=shannon.nelson@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.