[P4-dev] table questions

Ben Mack-Crane ben.mackcrane at corsa.com
Mon Jul 27 15:41:43 EDT 2015


In OpenFlow (which might be used as the run-time control protocol for a
P4-defined pipeline) there are a few options:

A flow_mod message can request to *add* or *modify* a table entry.If the
request is to add an entry and an entry with the same key (match condition)
already exists in the table the add fails and an error is returned.  If a
modify is requested and an entry with the same key is found in the table
that entry's action is replaced.  If a modify is requested and no matching
entry exists the request is silently ignored.

As LJ notes, there are other behaviors possible as well.  I am just
mentioning those currently defined in OpenFlow (looking at OF1.5).

As for adding the N+1st entry in an N entry table, in OpenFlow the default
is to fail the add request and return an error.  There is an option to
allow the switch to evict an entry of lower importance to make room for the
new entry.  Along with the eviction option bounds on available space in the
table can be set to generate notifications to the Controller when the free
space crosses a threshold (either getting smaller or larger).

Regards,
Ben


On Sun, Jul 26, 2015 at 11:32 AM, LJ Wobker <ljw at barefootnetworks.com>
wrote:

> Generally if you insert a new key it overwrites the existing one.  Keys
> are assumed to be unique.  I suppose you could design your target/API to
> have a different behavior, but I think the majority of use cases (think
> “updating routing information in the FIB”) are best served by the
> overwrite-if-exists semantic.
>
>
>
> The API will (or at least “should”) throw an error if you try to insert
> N+1 elements into a table of size N.  Again, I suppose you COULD write a
> target/API that behaves differently…
>
>
>
> The way the language is structured is that if you need to add headers to a
> packet, you need to have those headers represented in the parse graph, so
> that when the packet is deparsed to the wire you have that path in the
> parse tree.  So while you have have “different headers with varying
> lengths” you can’t really have “variable length headers”.  The parse tree
> must land on a node that has a fixed length.
>
>
>
> To do TLV type processing, you’d have to represent the length (generally
> by a branch based on the type) somewhere in the parse greph.
>
>
>
>
>
> --lj
>
>
>
>
>
>
>
>
>
>
>
> *From:* P4-dev [mailto:p4-dev-bounces at p4.org] *On Behalf Of *brian fiegen
> *Sent:* Sunday, July 26, 2015 4:48 AM
> *To:* p4-dev at p4.org
> *Subject:* [P4-dev] table questions
>
>
>
>
>
> I have a few questions about tables:
>
>    - suppose one inserts a <key1, value1> into a table and then at some
>    point in the future inserts a <key1, value2> into the table.  Does this
>    operation result in both entries in the table?  Or the most recent one?  Or
>    is the result of these operations unknown?
>    - if one defines a table to be of size 50 and there are 50 elements in
>    the table and 51st unique element is added to the table, what happens?Does
>    an error get returned and the 51st element isn’t inserted?  Does one of the
>    existing elements get randomly picked and removed to make room?
>    - Does a default table action consume a spot in the table?
>    - Is it possible to insert into a table a “value" which has variable
>    length?   Basically I’m thinking of this “value” as being a sequence of
>    bytes that are a header to be inserted into the packet.    What would be
>    the mechanism to reference and process this variable length byte sequence
>    on the action side?
>
> Thanks
>
>
>
> _______________________________________________
> P4-dev mailing list
> P4-dev at p4.org
> Listinfo - http://mail.p4.org/mailman/listinfo/p4-dev_p4.org
> Archives - http://mail.p4.org/pipermail/p4-dev_p4.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-dev_lists.p4.org/attachments/20150727/81ad2501/attachment-0001.html>


More information about the P4-dev mailing list