Hello,
I’m currently working on OVN to add MPLS logical fields (such as 'mpls_label',
'mpls_bos') to support BGP/MPLS technology.
As indicated in 'mf_field' struct in meta-flow.h, most OVS meta-flow fields
have n_bytes * 8 == n_bits size but there are few exceptions such as
'mpls_label', 'mpls_bos', etc…
In OVN case, when calling 'mf_mask_subfield' method from meta-flow.c, for
example for 'mpls_label' OVS meta-flow field which has 20 useful bits over 32
bits, the 'mask' value parsed in OVN is set to 0xffff00ff (which seems correct).
The problem is that in 'mf_set' method, 'mpls_label' OVS meta-flow field is
supposed to only have a NULL, all-1-bits or all-0-bits 'mask' value to be set,
as shown below:
uint32_t
mf_set(const struct mf_field *mf,
const union mf_value *value, const union mf_value *mask,
struct match *match, char **err_str)
{
if (!mask || is_all_ones(mask, mf->n_bytes)) {
mf_set_value(mf, value, match, err_str);
return mf->usable_protocols_exact;
} else if (is_all_zeros(mask, mf->n_bytes) && !mf_is_tun_metadata(mf)) {
/* Tunnel metadata matches on the existence of the field itself, so
* it still needs to be encoded even if the value is wildcarded. */
mf_set_wild(mf, match, err_str);
return OFPUTIL_P_ANY;
} …
switch (mf->id) {
…
case MFF_MPLS_LABEL:
case MFF_MPLS_TC:
case MFF_MPLS_BOS:
case MFF_MPLS_TTL:
…
return OFPUTIL_P_NONE;
…
}
However, as mentioned in 'mf_set' method comment, “The caller is responsible
for ensuring that 'match' meets 'mf''s prerequisites”.
So, since the 'mpls_label' OVS meta-flow field is indicated as not maskable in
meta-flow.h, shouldn't OVN ensure that 'mask' is set to NULL when calling
'mf_mask_subfield' ?
Best regards,
Yannick Thomas
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
