From: Thomas Graf <tgraf@suug.ch>
To: "Varlese, Marco" <marco.varlese@intel.com>
Cc: John Fastabend <john.fastabend@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
"Fastabend, John R" <john.r.fastabend@intel.com>,
"roopa@cumulusnetworks.com" <roopa@cumulusnetworks.com>,
"sfeldma@gmail.com" <sfeldma@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration
Date: Mon, 15 Dec 2014 14:07:49 +0000 [thread overview]
Message-ID: <20141215140749.GB21952@casper.infradead.org> (raw)
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104AC3914@IRSMSX108.ger.corp.intel.com>
On 12/11/14 at 09:59am, Varlese, Marco wrote:
> An example of attributes are:
> * enabling/disabling of learning of source addresses on a given port (you can imagine the attribute called LEARNING for example);
> * internal loopback control (i.e. LOOPBACK) which will control how the flow of traffic behaves from the switch fabric towards an egress port;
> * flooding for broadcast/multicast/unicast type of packets (i.e. BFLOODING, MFLOODING, UFLOODING);
All of these are highly generic and should *not* be passed through
from user space to the driver directly but rather be properly
abstracted as Roopa proposed. The value of this API is abstraction.
If we introduce per device attributes for generic functions we lose
large portions of the value gained.
You mentioned you have additional attributes in mind, maybe you can
give a few examples which are not generic, i.e. do not apply to
multiple vendors.
next prev parent reply other threads:[~2014-12-15 14:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 16:23 [RFC PATCH net-next 1/1] net: Support for switch port configuration Varlese, Marco
2014-12-10 16:50 ` Jiri Pirko
2014-12-10 17:03 ` John Fastabend
2014-12-11 9:59 ` Varlese, Marco
2014-12-11 11:01 ` Jiri Pirko
2014-12-11 12:02 ` Varlese, Marco
2014-12-11 13:08 ` Jiri Pirko
2014-12-11 13:55 ` Varlese, Marco
2014-12-11 16:37 ` Roopa Prabhu
2014-12-11 16:56 ` Jiri Pirko
2014-12-11 17:41 ` Roopa Prabhu
2014-12-11 17:54 ` Jiri Pirko
2014-12-11 17:55 ` John Fastabend
2014-12-12 9:19 ` Varlese, Marco
2014-12-13 7:06 ` Roopa Prabhu
2014-12-15 9:39 ` Varlese, Marco
2014-12-15 10:58 ` Arad, Ronen
2014-12-15 16:18 ` Roopa Prabhu
2014-12-13 14:39 ` Rosen, Rami
2014-12-15 14:07 ` Thomas Graf [this message]
2014-12-15 14:29 ` Varlese, Marco
2014-12-15 14:40 ` Thomas Graf
2014-12-15 16:44 ` Roopa Prabhu
2014-12-15 14:05 ` Thomas Graf
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=20141215140749.GB21952@casper.infradead.org \
--to=tgraf@suug.ch \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--cc=john.r.fastabend@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.varlese@intel.com \
--cc=netdev@vger.kernel.org \
--cc=roopa@cumulusnetworks.com \
--cc=sfeldma@gmail.com \
--cc=stephen@networkplumber.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).