From: Thomas Graf <tgraf@suug.ch>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
nhorman@tuxdriver.com, andy@greyhouse.net, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk,
stephen@networkplumber.org, jeffrey.t.kirsher@intel.com,
vyasevic@redhat.com, xiyou.wangcong@gmail.com,
john.r.fastabend@intel.com, edumazet@google.com
Subject: Re: [patch net-next RFC 2/4] net: introduce switchdev API
Date: Thu, 20 Mar 2014 13:59:01 +0000 [thread overview]
Message-ID: <20140320135901.GG16640@casper.infradead.org> (raw)
In-Reply-To: <1395243232-32630-3-git-send-email-jiri@resnulli.us>
On 03/19/14 at 04:33pm, Jiri Pirko wrote:
> +struct swdev_linked_ops {
> +};
I've been trying to think of better names for this to make
it absolutely clear which is which (linked ops vs. ops).
What do you think about the following?
sw_api -> sw_api_ops / sw_api_port_ops
|
sw_device
|
sw_driver -> sw_driver_ops / sw_driver_port_ops
> +bool swdev_dev_check(const struct net_device *dev);
> +void swdev_link(struct net_device *dev,
> + const struct swdev_linked_ops *linked_ops,
> + void *linked_priv);
> +void swdev_unlink(struct net_device *dev);
> +void *swdev_linked_priv(const struct net_device *dev);
> +bool swdev_is_linked(const struct net_device *dev);
> +int swdev_flow_insert(struct net_device *dev, struct sw_flow *flow);
> +int swdev_flow_remove(struct net_device *dev, struct sw_flow *flow);
> +int swdev_packet_upcall(struct net_device *dev, struct sk_buff *skb);
> +
> +struct swdev_ops {
> + const char *kind;
> + int (*flow_insert)(struct net_device *dev, struct sw_flow *flow);
> + int (*flow_remove)(struct net_device *dev, struct sw_flow *flow);
I think this API should be made more extendable. Flags might be
needed at some point or even switch specific configuration
blobs. How about adding a struct sw_flow_opts early on to avoid
cluttering the function parameter list later on?
> +int swdev_flow_insert(struct net_device *dev, struct sw_flow *flow)
> +{
> + struct swdev *sw = netdev_priv(dev);
> +
> + BUG_ON(!swdev_dev_check(dev));
How about taking the swdev struct instead to make it clear that
all these swdev_ functions are only supposed to be used with
swdev instances? We can translate the swdev pointer to a net_device.
> +bool swportdev_dev_check(const struct net_device *port_dev)
> +{
> + return port_dev->netdev_ops == &swportdev_netdev_ops;
> +}
> +EXPORT_SYMBOL(swportdev_dev_check);
Same as above
> +struct net_device *swportdev_create(struct net_device *dev,
> + const struct swportdev_ops *ops)
> +{
> + struct net_device *port_dev;
> + char name[IFNAMSIZ];
> + struct swportdev *swp;
> + int err;
Needs a check that dev is of the same family as the provided
port ops.
> + err = snprintf(name, IFNAMSIZ, "%sp%%d", dev->name);
> + if (err >= IFNAMSIZ)
> + return ERR_PTR(-EINVAL);
> +
> + port_dev = alloc_netdev(sizeof(struct swportdev), name, swportdev_setup);
> + if (!port_dev)
> + return ERR_PTR(-ENOMEM);
> +
> + err = register_netdevice(port_dev);
> + if (err)
> + goto err_register_netdevice;
> +
> + err = netdev_master_upper_dev_link(port_dev, dev);
> + if (err) {
> + netdev_err(dev, "Device %s failed to set upper link\n",
> + port_dev->name);
> + goto err_set_upper_link;
> + }
> + swp = netdev_priv(port_dev);
> + err = netdev_rx_handler_register(port_dev, swportdev_handle_frame, swp);
> + if (err) {
> + netdev_err(dev, "Device %s failed to register rx_handler\n",
> + port_dev->name);
> + goto err_handler_register;
> + }
> +
> + swp = netdev_priv(port_dev);
> + swp->ops = ops;
> + netif_carrier_off(port_dev);
> + netdev_info(port_dev, "Switch port device created (%s)\n", swp->ops->kind);
> + return port_dev;
> +
> +err_handler_register:
> + netdev_upper_dev_unlink(port_dev, dev);
> +err_set_upper_link:
> + unregister_netdevice(port_dev);
> +err_register_netdevice:
> + free_netdev(port_dev);
> + return ERR_PTR(err);
> +}
> +EXPORT_SYMBOL(swportdev_create);
next prev parent reply other threads:[~2014-03-20 13:59 UTC|newest]
Thread overview: 125+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 15:33 [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath Jiri Pirko
2014-03-19 15:33 ` [patch net-next RFC 1/4] openvswitch: split flow structures into ovs specific and generic ones Jiri Pirko
2014-03-20 13:04 ` Thomas Graf
2014-03-19 15:33 ` [patch net-next RFC 2/4] net: introduce switchdev API Jiri Pirko
2014-03-20 13:59 ` Thomas Graf [this message]
2014-03-20 14:18 ` Jiri Pirko
2014-03-20 14:43 ` Nikolay Aleksandrov
2014-03-20 15:42 ` Jiri Pirko
2014-03-19 15:33 ` [patch net-next RFC 3/4] openvswitch: Introduce support for switchdev based datapath Jiri Pirko
2014-03-19 15:33 ` [patch net-next RFC 4/4] net: introduce dummy switch Jiri Pirko
2014-03-20 11:49 ` [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath Jamal Hadi Salim
2014-03-20 12:40 ` Jiri Pirko
2014-03-20 17:21 ` Florian Fainelli
2014-03-21 12:04 ` Jamal Hadi Salim
2014-03-22 9:48 ` Jiri Pirko
2014-03-24 23:07 ` Jamal Hadi Salim
2014-03-25 17:39 ` Neil Horman
2014-03-25 18:00 ` Thomas Graf
2014-03-25 19:35 ` Neil Horman
2014-03-25 20:11 ` Florian Fainelli
2014-03-25 20:31 ` Neil Horman
2014-03-25 21:22 ` Jamal Hadi Salim
2014-03-25 21:26 ` Thomas Graf
2014-03-25 21:42 ` Florian Fainelli
2014-03-25 21:54 ` Thomas Graf
2014-03-26 10:55 ` Neil Horman
2014-03-26 5:37 ` Roopa Prabhu
2014-03-26 10:54 ` Jamal Hadi Salim
2014-03-26 15:31 ` John W. Linville
2014-03-26 16:54 ` Roopa Prabhu
2014-03-26 16:59 ` Jiri Pirko
2014-03-26 17:29 ` Florian Fainelli
2014-03-26 17:35 ` Jiri Pirko
2014-03-26 17:58 ` Florian Fainelli
2014-03-26 18:14 ` Jiri Pirko
2014-03-26 18:29 ` Hannes Frederic Sowa
2014-03-26 18:30 ` Florian Fainelli
2014-03-26 21:51 ` Jamal Hadi Salim
2014-03-26 22:22 ` Florian Fainelli
2014-03-26 22:53 ` Jamal Hadi Salim
2014-03-26 23:16 ` Florian Fainelli
2014-03-27 6:56 ` Jiri Pirko
2014-03-27 10:39 ` Jamal Hadi Salim
2014-03-27 10:50 ` Jiri Pirko
2014-03-27 11:12 ` Jamal Hadi Salim
2014-03-27 11:16 ` Jiri Pirko
2014-03-27 14:10 ` Sergey Ryazanov
2014-03-27 16:41 ` Florian Fainelli
2014-03-27 16:57 ` Jiri Pirko
2014-03-27 16:59 ` Thomas Graf
2014-03-27 20:32 ` Sergey Ryazanov
2014-03-27 21:20 ` Florian Fainelli
2014-03-27 21:55 ` Jamal Hadi Salim
2014-03-28 6:28 ` Jiri Pirko
2014-03-30 12:08 ` Alon Harel
2014-03-27 21:41 ` Jamal Hadi Salim
2014-03-27 16:55 ` Jiri Pirko
2014-03-27 19:58 ` Sergey Ryazanov
2014-03-27 20:01 ` Florian Fainelli
2014-03-27 20:04 ` Sergey Ryazanov
2014-03-27 21:47 ` Jamal Hadi Salim
2014-03-27 21:54 ` Florian Fainelli
2014-03-27 21:59 ` Jamal Hadi Salim
2014-03-27 22:19 ` Florian Fainelli
2014-03-27 23:42 ` Thomas Graf
2014-03-27 23:46 ` Florian Fainelli
2014-03-26 17:57 ` Roopa Prabhu
2014-03-26 18:09 ` Florian Fainelli
2014-03-27 13:46 ` John W. Linville
2014-03-26 17:47 ` Roopa Prabhu
2014-03-26 18:03 ` Jiri Pirko
2014-03-26 21:27 ` Roopa Prabhu
2014-03-26 21:31 ` Jiri Pirko
2014-03-27 15:35 ` Roopa Prabhu
2014-03-27 16:10 ` Jiri Pirko
2014-04-01 19:13 ` Scott Feldman
2014-04-02 6:41 ` Jiri Pirko
2014-04-02 15:37 ` Scott Feldman
2014-04-02 14:32 ` Andy Gospodarek
2014-04-02 15:25 ` John W. Linville
2014-04-02 16:15 ` Scott Feldman
2014-04-02 16:47 ` Florian Fainelli
2014-04-02 21:52 ` Thomas Graf
2014-04-02 19:29 ` John W. Linville
2014-04-02 19:54 ` Scott Feldman
2014-04-02 20:06 ` John W. Linville
2014-04-02 20:04 ` Stephen Hemminger
2014-04-02 20:23 ` Jiri Pirko
2014-04-02 20:38 ` John W. Linville
2014-04-02 21:36 ` Thomas Graf
2014-03-25 20:56 ` Jamal Hadi Salim
2014-03-25 21:19 ` Thomas Graf
2014-03-25 21:24 ` Jamal Hadi Salim
2014-03-26 7:21 ` Jiri Pirko
2014-03-26 11:00 ` Jamal Hadi Salim
2014-03-26 11:06 ` Jamal Hadi Salim
2014-03-26 11:31 ` Jamal Hadi Salim
2014-03-26 13:20 ` Jiri Pirko
2014-03-26 13:23 ` Jamal Hadi Salim
2014-03-26 13:17 ` Jiri Pirko
2014-03-26 11:10 ` Neil Horman
2014-03-26 11:29 ` Thomas Graf
2014-03-26 12:58 ` Jamal Hadi Salim
2014-03-26 15:22 ` John W. Linville
2014-03-26 21:36 ` Jamal Hadi Salim
2014-03-26 18:21 ` Neil Horman
2014-03-26 19:11 ` Florian Fainelli
2014-03-26 22:44 ` Jamal Hadi Salim
2014-03-26 23:15 ` Thomas Graf
2014-03-26 23:21 ` Florian Fainelli
2014-03-27 15:26 ` Neil Horman
2014-03-27 21:33 ` Jamal Hadi Salim
2014-03-26 19:24 ` Hannes Frederic Sowa
2014-03-27 13:43 ` John W. Linville
2014-03-26 12:19 ` Jamal Hadi Salim
2014-03-26 15:27 ` John W. Linville
2014-03-25 18:33 ` Florian Fainelli
2014-03-25 19:40 ` Neil Horman
2014-03-25 20:00 ` Florian Fainelli
2014-03-25 21:39 ` tgraf
2014-03-25 22:08 ` Jamal Hadi Salim
2014-03-26 5:48 ` Roopa Prabhu
2014-03-25 20:46 ` Jamal Hadi Salim
2014-03-26 7:24 ` Jiri Pirko
2014-03-22 9:40 ` Jiri Pirko
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=20140320135901.GG16640@casper.infradead.org \
--to=tgraf@suug.ch \
--cc=andy@greyhouse.net \
--cc=azhou@nicira.com \
--cc=ben@decadent.org.uk \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=edumazet@google.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse@nicira.com \
--cc=jiri@resnulli.us \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=ogerlitz@mellanox.com \
--cc=pshelar@nicira.com \
--cc=stephen@networkplumber.org \
--cc=vyasevic@redhat.com \
--cc=xiyou.wangcong@gmail.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 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).