Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New checksum APIs in v1model; better alias analysis in side-effects; … #858

Merged
merged 4 commits into from
Aug 23, 2017

Conversation

mihaibudiu
Copy link
Contributor

…removed some hacks from bmv2 backend which were related to checksums

This patch still does not generate JSON code for verifying checksum, but it should be very easy to add that capability now. There is a whole set of issues that should be addressed by this PR; I will list them separately.

@mihaibudiu
Copy link
Contributor Author

This PR should fix the following issues: #134, #445, #609, #741, #775, #840

@mihaibudiu
Copy link
Contributor Author

This PR simplifies the way checksums are computed and verified in v1model by using an extern function for each API; no extern objects exist anymore. This is much closer to the way BMv2 (and P4-14) handle checksums, so translation is much simpler in both directions. This new API also makes it much easier to give good error messages when users misuse the verify/update checksum controls.

The better alias analysis was needed so that the compiler does not mess up these nice extern function calls. On the positive side, a bunch of relatively hacky code to handle checksums in the BMv2 back-end has been completely removed.

/// Given a struct S { bit a; bit b; } and a variable S x;
/// a path can be x.a, or just x. An array index is represented as a
/// number (encoded as a string) or as "*", denoting an unknown index.
struct LocationPath : public IHasDbPrint {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would have been nice to make the changes to this pass in a separate PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but this PR would depend on that other one for being merged first.

@param data Data whose checksum is verified.
@param checksum Expected checksum of the data.
*/
extern void verify_checksum<T>(in bool condition, in T data, in bit<16> checksum);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason to limit these new extern methods to the "csum16" algorithm?
why not support verify_checksum<T, U>(in bool condition, in T data, in U checksum, in HashAlgorithm algo)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, but currently this is the only algorithm supported - at least in the back-end, so I didn't want to make the API more complicated than necessary.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that was my question. Is there a reason not to support the other algorithms in the backend? It looks like you would just need to map the enum value to the algo name and call createCalculation with that name as the first argument. It may be worth it to add support now rather than modify v1model.p4 in a non-backward compatible fashion in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will amend the PR with support for an algorithm parameter.
Only csum16 will be supported initially.

T must be a list expression where all the fields are bit-fields or varbits
and where the total dynamic length of the fields is a multiple of 16 bits.
If this method detects that a checksum of the data is not correct it
sets an internal error flag.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't the plan to expose this information as standard_metadata which can be consumed in ingress?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but that will be a separate PR.

@mihaibudiu
Copy link
Contributor Author

@antoninbas : this additional commit adds the Algorithm argument to the two checksum methods.

@antoninbas
Copy link
Member

@mbudiu-vmw I believe that the destination field's type need to be a generic type (e.g. needs to be bit<32> for a crc32 algorithm).

@mihaibudiu
Copy link
Contributor Author

I hope I have addressed all of @antoninbas comments.
Still pending: doing checksum verification - issue #675 - and separating verification from update.
I will probably have a single separate PR for both of these.

@mihaibudiu mihaibudiu merged commit f09a95d into p4lang:master Aug 23, 2017
@mihaibudiu mihaibudiu deleted the checksum branch August 23, 2017 21:54
cc10512 pushed a commit to cc10512/p4c that referenced this pull request Aug 29, 2017
…ffects; … (p4lang#858)"

This reverts commit f09a95d.

This commit breaks all existing programs using checksums. This is a
change that needs to be staged more carefully, announced on the
mailing list and deprecate the old way in a more graceful manner,
giving people the chance of transitioning their programs.
antoninbas pushed a commit that referenced this pull request Aug 29, 2017
…ffects; … (#858)"

This reverts commit f09a95d.

This commit breaks all existing programs using checksums. This is a
change that needs to be staged more carefully, announced on the
mailing list and deprecate the old way in a more graceful manner,
giving people the chance of transitioning their programs.
ChrisDodd pushed a commit to ChrisDodd/p4c that referenced this pull request Sep 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants