Several questions.

1. What was the driver of implementing interface-level pcp settings?

For example, currently pcp can be set on per-mbuf basis for the "real" vlans, which can give more granular control on the outgoing traffic.
Personally it is a bit hard for me to see the benefits of having the same pcp applied to all packets from the host.
Typically this kind of configuration can be easily configured on the access switch and host is supposed to be able to do more fine-granular control.
What comes into my mind is having something like dscp-to-pcp map, which allows user to benefit from all existing dscp manipulation framework.
What do you think?

2. Have you performed interop testing for the non-routable protocols like lldp, stp, lacp, etc?

Having seen some issues related to the routers/switches control plane forgetting to remove similar "dummy" headers, I'd recommend to perform validation with multiple vendors before committing this.

In D14702#309569, @melifaro wrote:

Several questions.

1. What was the driver of implementing interface-level pcp settings?

For example, currently pcp can be set on per-mbuf basis for the "real" vlans, which can give more granular control on the outgoing traffic.

This is supported in the patch as well. If the scheduled mbuf has 8021Q tag attached, the pcp value from the tag is inserted into the VLAN frame tag.
If you look at the code, you will see that I extracted the fragment from vlan_trasnmit() to reuse in both places.

Personally it is a bit hard for me to see the benefits of having the same pcp applied to all packets from the host.
Typically this kind of configuration can be easily configured on the access switch and host is supposed to be able to do more fine-granular control.

I think that this is complimentary, and one method of manipulating pcp does not exclude the validity, and apparent usefulness, of another.
The patch was written because there are users who need this feature (I cannot say more).

What comes into my mind is having something like dscp-to-pcp map, which allows user to benefit from all existing dscp manipulation framework.
What do you think?

Perhaps yes, but this is out of scope of the change. If pcp is already assigned, it will be honored. The assignment should be managed by the layer above the place where the framing and transmit are performed.

2. Have you performed interop testing for the non-routable protocols like lldp, stp, lacp, etc?

Having seen some issues related to the routers/switches control plane forgetting to remove similar "dummy" headers, I'd recommend to perform validation with multiple vendors before committing this.

No, no interop testing was done. As an anecdote, I can say that my home switch filters the vid 0 packets outright. More, Mellanox driver has the flow table programmed to drop such packets as well, right now (the fix is already worked out).

The feature is disabled by default, so I do not see it as critical or even important that some stuff would break when vid 0 encapsulation is enabled. The feature is added for the cases where it works.

In D14702#309602, @kib wrote:

In D14702#309569, @melifaro wrote:

Several questions.

1. What was the driver of implementing interface-level pcp settings?

For example, currently pcp can be set on per-mbuf basis for the "real" vlans, which can give more granular control on the outgoing traffic.

This is supported in the patch as well. If the scheduled mbuf has 8021Q tag attached, the pcp value from the tag is inserted into the VLAN frame tag.
If you look at the code, you will see that I extracted the fragment from vlan_trasnmit() to reuse in both places.

Ah, my bad. I haven't noticed the 8021q tag override part. In that case it's more like setting default pcp.

Personally it is a bit hard for me to see the benefits of having the same pcp applied to all packets from the host.
Typically this kind of configuration can be easily configured on the access switch and host is supposed to be able to do more fine-granular control.

I think that this is complimentary, and one method of manipulating pcp does not exclude the validity, and apparent usefulness, of another.
The patch was written because there are users who need this feature (I cannot say more).

What comes into my mind is having something like dscp-to-pcp map, which allows user to benefit from all existing dscp manipulation framework.
What do you think?

Perhaps yes, but this is out of scope of the change. If pcp is already assigned, it will be honored. The assignment should be managed by the layer above the place where the framing and transmit are performed.

2. Have you performed interop testing for the non-routable protocols like lldp, stp, lacp, etc?

Having seen some issues related to the routers/switches control plane forgetting to remove similar "dummy" headers, I'd recommend to perform validation with multiple vendors before committing this.

No, no interop testing was done. As an anecdote, I can say that my home switch filters the vid 0 packets outright. More, Mellanox driver has the flow table programmed to drop such packets as well, right now (the fix is already worked out).

The feature is disabled by default, so I do not see it as critical or even important that some stuff would break when vid 0 encapsulation is enabled. The feature is added for the cases where it works.

That's the topic we see differently. The functionality indeed is not used by default, however the actual code complicates ether_output(). Furthermore, I'm afraid that after someone actually tries to use this, the code will get more complicated. I'd really appreciate if you could change the ether_output() part to call the (inlined) function doing all of the business logic for handling pcp.

In D14702#309660, @melifaro wrote:

In D14702#309602, @kib wrote:

The feature is disabled by default, so I do not see it as critical or even important that some stuff would break when vid 0 encapsulation is enabled. The feature is added for the cases where it works.

That's the topic we see differently. The functionality indeed is not used by default, however the actual code complicates ether_output().

Indeed, it complicates the function because it adds the new feature.

Furthermore, I'm afraid that after someone actually tries to use this, the code will get more complicated. I'd really appreciate if you could change the ether_output() part to call the (inlined) function doing all of the business logic for handling pcp.

Can you explain more explicitly what do you want to change ? The only interpretation for your words which I was able to construct is that you want ether_8021q_frame() to become inlined in ether_output_frame(). Is it correct ?
If yes, I do not see much sense in it, because ether_8021q_frame() is only called for non-default path, and it really makes sense to keep ether_output_frame() short to not pollute icache.

In D14702#309683, @kib wrote:

In D14702#309660, @melifaro wrote:

In D14702#309602, @kib wrote:

The feature is disabled by default, so I do not see it as critical or even important that some stuff would break when vid 0 encapsulation is enabled. The feature is added for the cases where it works.

That's the topic we see differently. The functionality indeed is not used by default, however the actual code complicates ether_output().

Indeed, it complicates the function because it adds the new feature.

Furthermore, I'm afraid that after someone actually tries to use this, the code will get more complicated. I'd really appreciate if you could change the ether_output() part to call the (inlined) function doing all of the business logic for handling pcp.

Can you explain more explicitly what do you want to change ? The only interpretation for your words which I was able to construct is that you want ether_8021q_frame() to become inlined in ether_output_frame(). Is it correct ?
If yes, I do not see much sense in it, because ether_8021q_frame() is only called for non-default path, and it really makes sense to keep ether_output_frame() short to not pollute icache.

No, not exactly.

/* ether_otput_frame() */

if (ifp->if_pcp != IFNET_PCP_NONE) {
  if (ether_set_pcp(&m) != 0)
   return 0;
}

/* ether_set_pcp() */

/*
 * De-facto ether_8021q_frame() either produces new mbuf,  or fails to do so and produces an error.
 * Make its semantic consistent: either
 * 1) return/set new mbuf
 * or
 * 2) free resources and fill in errmsg.
 * With that change, an intermediate function can look like the following:
*/
eh = mtod(m, struct ether_header *);
if (ntohs(eh->ether_type) != ETHERTYPE_VLAN) {
  ether_8021q_frame(&m, &error);
  if m == NULL {
     print(error)
     return (1);
  }
}
return 0;