[P4-dev] Potential contributions to extern functionality
iped at seas.upenn.edu
Thu Oct 4 15:40:06 EDT 2018
Thanks for your reply. Following up on this:
The modifications to simple switch that we have made to allow for new
packet injection into arbitrary stages of the switch pipeline require
access to the switch object from within an extern. To enable this
functionality, we have modified the simple switch to provide a global,
singleton reference so it can be accessed when necessary.
While this fits our needs, I'm aware the implementation is not ideal for
many cases, and am interested to find out if, perhaps with a little more
work, I can arrive at an implementation that can benefit the wider P4 BMv2
community. If you have any guidance on a better way to implement the
feature I could try to go about it.
In case it's not possible for me to develop a more acceptable patch within
the time I can commit, I'd like to ask if anybody else on the list has
advice on maintaining out-of-tree patches in our BMv2 fork moving forward,
as the bmv2 repo undoubtedly undergoes changes.
My question is: given few but significant changes to a behavioral model
target, how have other teams maintained their code (which may not be
suitable for inclusion in the behavioral-model repo) while keeping
up-to-date with changes? Ultimately, we are attempting to keep the
simple-switch architecture, with the addition of some functionality added
Thank you for your time,
On Thu, Sep 27, 2018 at 4:20 AM Antonin Bas <antonin at barefootnetworks.com>
> Hi Isaac,
> Yes, please try to submit your features as separate pull requests.
> Also before submitting a patch, please ask yourself these questions:
> - does it belong in the core library (bm_sim) and can be used by several /
> most architectures, or is it architecture specific?
> - does it slow down packet processing for P4 programs that do not utilize
> the new feature?
> - if adding a feature to simple_switch, it is something that is required
> by the P4_16 v1model architecture - or at least compatible with it?
> For example, 3) (timer) seems like a good candidate for the bmv2 core
> library, providing that it is implemented in such a way that there is no
> penalty for programs that do not require it.
> Looking forward to review your PRs.
> On Wed, Sep 26, 2018 at 11:53 AM Isaac Pedisich <iped at seas.upenn.edu>
>> Dear All,
>> Recently, we have made some small modifications (fewer than 200 lines) to
>> the behavioral model's simple switch target to introduce a bit of new
>> functionality, centered around easing the execution of arbitrary externs.
>> We'd like to explore the options of giving these changes to the community.
>> There are three pieces of functionality that these modifications
>> implement. In brief, they are:
>> 1) Packet serialization: We implemented a few functions to serialize an
>> entire packet (including valid headers, or a manually specified set of
>> headers) into a character array. We also implemented deserialization back
>> into the packet and headers, so packets can be modified within an extern
>> that expects to operate on packets as byte arrays.
>> 2) Packet creation: We implemented functions to inject arbitrarily
>> generated packets into various stages in the pipeline, allowing externs to
>> generate entirely new packets.
>> 3) Periodic extern-helper execution: This allowed extern functions to
>> register a callback and interval to the switch. If the extern is declared
>> in the P4 code, the callback is called every time the interval elapses.
>> We would gladly work with the community to make the changes acceptable to
>> you, if you feel that the changes would be as helpful to others as they
>> have been to us.
>> To facilitate merging, we are happy to submit these features as separate
>> pull requests so they may be accepted independently of one another.
>> Thank you.
>> P4-dev mailing list
>> P4-dev at lists.p4.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the P4-dev