Add "What is included" section to README

[jafingerhut]

@pkotikal @vgurevich I would appreciate your comments on this PR, in case I am leaving anything out.

[vgurevich]

I've left a couple of comments.

[vgurevich]

The official name is BRI -- Barefoot Runtime Interface, which consists of two components (APIs):

• The locally callable BfRt API (with bindings in C and C++)
• The gRPC-based protocol, called BF Runtime, together with the server implementation in C++ and both C++ and Python client bindings (others can be generated using the provided proto files as well)
  ** The additional bfrt_grpc.client Python module provides easier-to-use, simplified interface to BF Runtime (used for most PTF tests, for example)

[vgurevich]

If I parse it in a "lawerly" way, you might be right, but few people will realize that while the repo does, indeed, allow one to develop the P4 code that would run on both ASIC and the model, it will not allow one to develop the control plane SW that runs on anything but the model :)

I would re-word to make the lack of support for running the code on the ASICs more explicit.

[vgurevich]

The purpose of BSP is to allow the SDE to access and manage board-specific components, necessary for port management. Without the BSP you can't really have links on physical ports.

It is not used to boot hardware boards (and it is not the purpose of the SDE to begin with)

[jafingerhut]

@vgurevich Thanks for the detailed comments. I have attempted to address your first 3 comments with the changes in commit 5 of this PR. If you could give it one more look to see if I've messed up somehow, that would be appreciated.

[vgurevich]

Sorry, @jafingerhut -- you know I like to comment :)

[vgurevich]

remove the word "successfully" -- P4i is often quite useful precisely when the programs are not successfully compiled.

[vgurevich]

... and manage related components, such as repeaters, retimers, SFPs, QSFPs, etc.

[vgurevich]

ASIC-specific SerDes drivers. These are not necessary to run the simulation model, but essential for running the code on the real ASICs

[jafingerhut]

@vgurevich I believe I've addressed all of your second round of comments. Keep them coming, if you have more, otherwise please approve the PR.

[vgurevich]

Already done!

[jafingerhut]

@pkotikal Please take quick look at this and see if you notice anything misstated here, or other things included or missing that are not mentioned. Thanks.

[pkotikal]

@pkotikal Please take quick look at this and see if you notice anything misstated here, or other things included or missing that are not mentioned. Thanks.

Thanks Andy. Only one comment - the bf-drivers build instructions for HW are here - https://github.com/p4lang/open-p4studio/blob/main/hw/RDC_README. The vendor specific files and patches need to be downloaded from Intel RDC.

[jafingerhut]

@pkotikal Thanks for the note.

I am confused, though. Some Tofino driver code must be running in order to successfully run the PTF test that has been passing so far, even though the hw directory contains no code when doing the builds that successfully pass those tests.

Are you saying that in order to build a version of the Tofino drivers that runs with real hardware, you need to follow the instructions?

I will assume yes for now, create a proposed PR that tries to explain that, and ask you and Vlad to review.

[pkotikal]

@pkotikal Thanks for the note.

I am confused, though. Some Tofino driver code must be running in order to successfully run the PTF test that has been passing so far, even though the hw directory contains no code when doing the builds that successfully pass those tests.

Are you saying that in order to build a version of the Tofino drivers that runs with real hardware, you need to follow the instructions?

I will assume yes for now, create a proposed PR that tries to explain that, and ask you and Vlad to review.

That's right @jafingerhut, we are building the driver that works with tofino-model for the PTF tests. @ansamalintel, could you please elaborate on the bf-drivers build for HW. Thanks!

[ansamalintel]

@jafingerhut Some of the driver source files call third-party proprietary APIs to program their corresponding hardware components. For instance, to program Credo Serdes, we use the API provided by Credo SDK. We requested permission to include these APIs in our Tofino open-source repository, but we did not receive a positive response. Therefore, we decided to remove source code that exposes third-party vendor-specific APIs from our Tofino open-source code.