[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100830062755.GA22396@verge.net.au>
Date: Mon, 30 Aug 2010 15:27:55 +0900
From: Simon Horman <horms@...ge.net.au>
To: netdev@...r.kernel.org
Cc: Jesse Gross <jesse@...ira.com>,
Stephen Hemminger <shemminger@...ux-foundation.org>,
Chris Wright <chrisw@...s-sol.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
Arnd Bergmann <arnd@...db.de>,
David Miller <davem@...emloft.net>
Subject: [rfc] Merging the Open vSwitch datapath
Hi,
I am looking to submit the Open vSwitch datapath for merging into the
kernel. To this end I have posted a preliminary round of patches to the
dev@...nvswitch.org mailing list (unfortunately the online archive seems
incomplete). It seems to me that I am now at or close to the point where
the patches can be posted to netdev. However, I have a few questions.
1) The current patches place the datapath in drivers/staging/ovs-datapath.
It has been proposed that net/openvswitch would be a better location.
What is the feeling of netdev on this?
In a similar vein. Open vSwitch has some headers that are shared
with user-space. Is include/net/openvswitch an acceptable location
for those headers?
2) The code could do with some cleaning up. The current todo list
includes the following items.
* Use pr_*
* Remove trailing whitespace and other formatting fixes
* Stephen Hemminger would like make_writable() removed in favour
of using skb_cow_data() or made generic.
http://openvswitch.org/pipermail/dev_openvswitch.org/2010-August/002993.html
* Removal of compatibility code
* Possible use of netlink for user-space interface
* Network namespace support
While the last two items seem to be post-merge material to me.
I am wondering if it is ok to handle the other items post-merge too.
As the person doing the merge, this would make my life a lot easier
but I'm unclear if it is an acceptable approach or not.
About Open vSwitch:
(Text by Jesse Gross)
Open vSwitch is a multilayer Ethernet switch targeted at virtualized
environments. In addition to supporting a variety of features
expected in a traditional hardware switch, it enables fine-grained
programmatic extension and control through the OpenFlow protocol.
This control is useful in a wide variety of applications but is
particularly important in multi-server virtualization deployments,
which are often characterized by highly dynamic endpoints and the need
to maintain logical abstractions for multiple tenants.
The Open vSwitch datapath provides an in-kernel fast path for packet
forwarding. It is complemented by a userspace daemon, ovs-vswitchd,
which is able to accept configuration from a variety of sources and
translate it into packet processing rules.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists