[2/N] Add option context

[cccclai]

Stack from ghstack (oldest at bottom):

• [5/N] Add get_option/set_option APIs #11758
• [4/N] Add backend options map #11462
• [3/N] Add get_option/set_option function in backend interface #11391
• -> [2/N] Add option context #11390
• [1/N] Add BackendOptions class #11389

For future needs without breacking API BC, in case we need to pass more information to the update API

Differential Revision: D75919212

Differential Revision: D75919212

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/11390

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 2 New Failures, 2 Unrelated Failures

As of commit a0beade with merge base 608a745 ():

NEW FAILURES - The following jobs have failed:

• Lint / lintrunner / linux-job (gh)
  >>> Lint for runtime/backend/backend_option_context.h:
• pull / test-llava-runner-linux / linux-job (gh)
  RuntimeError: Command docker exec -t 6a88e9c7dd9ed180960f4d1ead9ea50a3e44e6dac4907e34e9bd980005211d83 /exec failed with exit code 139

FLAKY - The following jobs failed but were likely due to flakiness present on trunk:

• pull / test-llama-runner-linux (fp32, xnnpack+quantize_kv, linux.arm64.2xlarge, executorch-ubuntu-22.04-... / linux-job (gh) (matched linux rule in flaky-rules.json)
  The process '/usr/bin/git' failed with exit code 128
• pull / test-models-linux-basic (mv3, portable, buck2, linux.2xlarge, executorch-ubuntu-22.04-clang12) / linux-job (gh) (detected as infra flaky with no log or failing log classifier)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212

[kimishpatel]

I am not sure on the use of this. I understand you said this is introduced for BC, but can you elaborate on the BC aspect of it? Is it to avoid makign changes to client call sites? If this struct is populated then I imagine it will require client callsites to change anyway, if they want to make use of it. So maybe a bit more on this in the summary would be good.

If you do want to keep it then maybe get_option and set_option should provide both overloads? One with backendoptioncontext and one without..

[cccclai]

I am not sure on the use of this. I understand you said this is introduced for BC, but can you elaborate on the BC aspect of it? Is it to avoid makign changes to client call sites? If this struct is populated then I imagine it will require client callsites to change anyway, if they want to make use of it. So maybe a bit more on this in the summary would be good.

If you do want to keep it then maybe get_option and set_option should provide both overloads? One with backendoptioncontext and one without..

Yeah to avoid making change to client call sites. I was thinking it's for pupulating runtime info from ET to the backend during set option. We can take a look at how init context helps on passing new info from ET to backend without causing BC.

Like when we pass event tracer: 0c4053e

And the named data map:
492366a

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D75919212