[ovs-discuss] About porting ovs to the hardware platform.

Ben Pfaff blp at nicira.com
Wed Apr 24 17:22:03 UTC 2013


On Wed, Apr 24, 2013 at 05:40:34AM +0000, Lin Shaun wrote:
> Excuse me, I have studied PORTING document in ovs source.If i want to
> port ovs into the hardware switch (embedded linux, asic support L2/L3
> table)Should I use the kernel datapath? or I just use userspace ovs
> and write netdev-provider/dpif-providerto communication the network
> device of ASIC?

PORTING is intended to lay out the tradeoffs to help you make your own
decision.  If we just tell you "You should do X," then there was no
point in writing it.

Here's the key section again:

Porting Strategies
------------------

After a netdev provider has been implemented for a system's network
devices, you may choose among three basic porting strategies.

The lowest-effort strategy is to use the "userspace switch"
implementation built into Open vSwitch.  This ought to work, without
writing any more code, as long as the netdev provider that you
implemented supports receiving packets.  It yields poor performance,
however, because every packet passes through the ovs-vswitchd process.
See INSTALL.userspace for instructions on how to configure a userspace
switch.

If the userspace switch is not the right choice for your port, then
you will have to write more code.  You may implement either an
"ofproto provider" or a "dpif provider".  Which you should choose
depends on a few different factors:

    * Only an ofproto provider can take full advantage of hardware
      with built-in support for wildcards (e.g. an ACL table or a
      TCAM).

    * A dpif provider can take advantage of the Open vSwitch built-in
      implementations of bonding, LACP, 802.1ag, 802.1Q VLANs, and
      other features.  An ofproto provider has to provide its own
      implementations, if the hardware can support them at all.

    * A dpif provider is usually easier to implement, but most
      appropriate for software switching.  It "explodes" wildcard
      rules into exact-match entries.  This allows fast hash lookups
      in software, but makes inefficient use of TCAMs in hardware
      that support wildcarding.




More information about the discuss mailing list