Broadcom SDK

[Jason Lixfeld]

I understand that one needs to sign an NDA with Broadcom in order to use their SDK to roll a forwarding engine.

Anyone have any pointers on who within Broadcom I can contact to start this ball rolling?

Thanks!

[Rob Sherwood]

I can try to follow up with some introductions offline, but I *believe* they try to give access to the code predominantly as part of a larger commercial agreement.

That said, they have posted a binary driver called OF-DPA that exports a good chunk of the SDK's functionality.  I would start there:

https://github.com/Broadcom-Switch/of-dpa

I'm actually in the process of producing a precompiled binary of it for ONL that installs by default.  Unfortunately I haven't had a chance to push through with this :-(

More news on that front as it comes.

- Rob

.

--
You received this message because you are subscribed to the Google Groups "opennetworklinux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opennetworklin...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Lixfeld]

The driver seems very OF heavy as opposed to the more L3/MPLS heavy stuff I'd need to be able to interface with, but it's a good read!  Thanks for any pointers!

[Rob Sherwood]

Agreed.  Broadcom folks also mentioned at a recent Open Compute that they were going to release a lighter weight library called OpenNSL.  More news as that becomes available.

Just so folks don't get too hung up on broadcom, other ASIC manufacturers are trying to move in the same direction.  I'm trying to track the information here, but if anyone knows of more up to date information, please let me know.

[from http://opennetlinux.org/faq]

• Is there any open source (or at least open) SDKs for managing the packet forwarding hardware?

  Yes -- you need to match the SDK to the underlying forwarding hardware. Some of these projects are changing rapidly and some are announcements where the code is expected to come shortly. An incomplete list of SDKs are that available include:

  • Broadcom OF-DPA SDK: (actual code!) https://github.com/Broadcom-Switch/of-dpa/
  • Mellanox Open Ethernet: (code coming soon) http://www.mellanox.com/openethernet/
  • Centec's Lantern Project: (code needs link) http://www.centecnetworks.com/en/NewsView.asp?ID=274&SortID=48#sthash.lZZdT6gK.dpbs

[Tom Lanyon]

Sorry to resurrect an old thread - I was just wondering whether anything much came of this discussion?

I've been looking to utilise some switches based on Trident+ or Trident2 however none of the available operating systems appear take advantage of the features I'm looking for (which are seemingly implemented in the Broadcom hardware) like MAC-in-MAC/802.1ah tunnels.

As far as I can tell, the only way for me to take advantage of this is to use ONL and implement a custom forwarding engine with the Broadcom SDK, but that's only available under NDA under 'larger commercial agreements' as Rob mentions below.  Is that still accurate today or do I have other options?

-Tom

[Rob Sherwood]

Hi Tom,

Sorry for the slow reply.  Unfortunately, there has not been a lot of movement on this thread yet and it's still an issue.  Yes, you are correct that right now, the only way to actually program the forwarding chip is under a commercial agreement (although typically just an NDA) with the chip manufacturers.

That said, this is obviously problematic so as companies have started to come out with closed source but open APIs SDKs, the intent is to provide precompiled binaries of the SDKs on top of ONL.  For example, Broadcom has the OF-DPA and OpenNSL projects, Mellanox has their Open Ethernet project, Centec has their latern project.  The idea is to provide the precompiled binary for those SDKs so that folks who are not under NDA with Broadcom can still write code and program the forwarding hardware.

This is the intent -- the problem is that we need to find people who *are* under NDA with the above companies to compile the software.  Big Switch is currently trying to hire people precisely to do this, but hiring good folks takes time.  If anyone works at a company who is under NDA with one of these companies and would like to work to port one of them to ONL, the help is most appreciated.

- Rob

.

[Thenralarasan Murugesan]

Hi Rob,

I'm a newbie for Broadcom SDK forwarding plane.(Trident -II ASIC)

1. Where the Broadcom SDK running? Kernel space or User space of ONL?

2. Broadcom SDK is .ko module? or a library in user space?

2. I assume the Broadcom SDK using PCIe driver calls to reach BCM ASIC from P2020-CPU. Then what are linux-kernel-bde.ko and linux-user-bde.ko? refered in OF-DPA

3. Is there any way to access the Broadcom SDK without OF APIs? Wether Broadcom provides those APIs?

I request your help on above mentioned queries.

Thanks,

Thenral.

[Rob Sherwood]

Hi Thenral,

The Broadcom SDK has both userspace and kernel space components.  That said, typically most of the applications that write against the SDK are user space.  The linux-{kernel,user}-bde.ko files have just last week (!!) been open sourced, so you can see exactly what they do here: https://github.com/Broadcom-Switch/OpenNSL/blob/master/sdk-6.4.6-gpl-modules/systems/bde/linux/kernel/linux-kernel-bde.c

Currently, the Broacom SDK itself is both closed source (except for the kernel modules above) and closed API.  Closed API means that you can't even publish/distribute code that links against the SDK.  So, Broadcom has created two closed source but *open* API SDKs on top: OpenNSL (https://github.com/Broadcom-Switch/OpenNSL) and OF-DPA (https://github.com/Broadcom-Switch/of-dpa).  You can write what ever code you want to those APIs -- OpenFlow or not.  It's worth noting that OF-DPA is in theory designed to make it easier to write OpenFlow applications to it (like our Indigo openflow agent: https://github.com/opennetworklinux/ofdpa-2.0/tree/master/modules/indigo_ofdpa_driver/module/src), but you can of course use the API in any way that you want.

Hope that helps,

- Rob

.

[Lorenzo Fedi]

Hi All, 

Sorry for returning on this argument, but as today the path to follow for licensing the OpenNSL SDK OEM/ODP version under NDA with Broadcom is still very much unclear.

Our company is willing to access the licensed version SDK as soon as possible but we do not seem to find a proper way to do that.

Any help or information from the community? Mr. Sherwood, may we kindly ask if you can share some contact reference in Broadcom that manages the licensing requests?

Thanks, any help will be very much appreciated.

Lorenzo Fedi