-
Notifications
You must be signed in to change notification settings - Fork 41
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
Feat backend separate transport specific messages #343
Feat backend separate transport specific messages #343
Conversation
FabricsPath fabrics = 5 [(google.api.field_behavior) = OPTIONAL]; | ||
} | ||
|
||
message FabricsPath { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like we have tuple: (addr, port, nqn)
for target and again (addr, port, nqn)
for source, no ?
maybe we can somehow capture this in it's own message ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The traddr for the target is in the common part (it's the BDF for PCIe), so it needs to be split across two objects here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benlwalker WDYT about struct spdk_nvme_transport_id
?
https://github.com/spdk/spdk/blob/ee9fb405bfa6f11b75788c38752b2494598bbbd8/include/spdk/nvme.h#L455-L501
I think it is pretty good abstraction what we want to adopt here, why not ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do like that abstraction. To make that work here you'd need to have a FabricsPath with a source and target transport id, and then a MemoryBusPath with just a target transport id (or just traddr), and put the two into a OneOf.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My goal was to have the annotations as precise as possible, in order to provide a correct docs and benefit from some automatic validation tools like fieldbehavior.ValidateRequiredFields()
call.
If we extract those members into a separate message, we probably need to mark nqn
and port
as OPTIONAL
, since they are not applicable for pcie case, "lying" that they are actually required for fabrics. In the current patch, we clearly state that nqn
and port
are required by fabrics and not used by pcie
FabricsPath fabrics = 5 [(google.api.field_behavior) = OPTIONAL]; | ||
} | ||
|
||
message FabricsPath { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The traddr for the target is in the common part (it's the BDF for PCIe), so it needs to be split across two objects here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
361be99
to
4618e5f
Compare
Signed-off-by: Artsiom Koltun <artsiom.koltun@intel.com>
Signed-off-by: Artsiom Koltun <artsiom.koltun@intel.com>
Signed-off-by: Artsiom Koltun <artsiom.koltun@intel.com>
For continuation of the discussion in #330