Re: [ovs-dev] Path MTU discovery on GRE interfaces

[Matthias May via dev]

On 24/06/2021 05:51, Jesse Gross wrote:
> On Wed, Jun 23, 2021 at 10:06 AM Ben Pfaff  <mailto:b...@ovn.org>> wrote:
> 
> [updating Jesse's email address]
> 
> On Wed, Jun 23, 2021 at 04:48:29PM +0200, Matthias May via dev wrote:
> > I'm currently fighting with issues where TCP/UDP frames that are larger 
> than the MTU of a GRE tunnel are dropped.
> > I'm aware of the whys and how to work around the issue, but while 
> looking for solutions i stumbled over the fact that:
> > * [1] added PMTUD support to OVS
> > * [2] disabled/removed with v1.9.0 respectively v1.10.0 the feature
> >
> > Even after some significant time looking through the history i haven't 
> found a reason why this was removed, just
> that it
> > was removed.
> >
> > I started some preliminary work to add PMTUD support to OVS (again), 
> but the fact that it was removed 8 years ago
> seems
> > to me like a red flag to not do it (again).
> >
> > Could someone fluent with the OVS history from 8 years ago shed some 
> light on why PMTUD support was dropped?
> > Any pointers to a thread on this topic?
> 
> It was a layering violation.  This caused problems like, for example,
> not having a good IP address to send the "frag needed" message from.
> 
> 
> In terms of the history, I believe what happened is that PMTUD support was 
> added before the kernel module was
> upstreamed. When we later submitted the code upstream, we knew that it would 
> not fly due to the layering violations so
> support was removed before submitting.
> 
> However, as Dan mentioned, I believe that check_pkt_len can be used to 
> implement essentially the same behavior and it is
> upstream as it is more generic. It should still only be used in the context 
> of an L3 operation to avoid introducing the
> same layering issues though.


Thank you for your input.
I haven't done anything with check_pkt_len yet, but this seems promising.

Currently i simply ignore the DF bit and force fragmentation on the tunnel 
between the two sites.
After all, the proper solution is to set the MTU correctly on all involved 
devices.
--> I already don't have an issue for proper devices.

This is to work around some "industrial" devices that simply don't have the 
option to reduce the MTU, don't implement
DHCP option 26, and where the performance hit by doing fragmentation is too 
high.
IMO these devices are broken already. Being forced to have to work with them 
means that breaking L2/L3 layering to make
them work a bit better are probably the least of the issue(s).

BR
Matthias

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Path MTU discovery on GRE interfaces

[Matthias May via dev]

On 23/06/2021 19:06, Ben Pfaff wrote:
> [updating Jesse's email address]
> 
> On Wed, Jun 23, 2021 at 04:48:29PM +0200, Matthias May via dev wrote:
>> I'm currently fighting with issues where TCP/UDP frames that are larger than 
>> the MTU of a GRE tunnel are dropped.
>> I'm aware of the whys and how to work around the issue, but while looking 
>> for solutions i stumbled over the fact that:
>> * [1] added PMTUD support to OVS
>> * [2] disabled/removed with v1.9.0 respectively v1.10.0 the feature
>>
>> Even after some significant time looking through the history i haven't found 
>> a reason why this was removed, just that it
>> was removed.
>>
>> I started some preliminary work to add PMTUD support to OVS (again), but the 
>> fact that it was removed 8 years ago seems
>> to me like a red flag to not do it (again).
>>
>> Could someone fluent with the OVS history from 8 years ago shed some light 
>> on why PMTUD support was dropped?
>> Any pointers to a thread on this topic?
> 
> It was a layering violation.  This caused problems like, for example,
> not having a good IP address to send the "frag needed" message from.
> 
> Jesse may remember more.
> 

OK i guessed as much.
I was thinking about what address to use when there is none available.
Maye the least breaking thing would be to just use as source of the ICMP 
unreachable the destination to which the frames
are addressed.

BR
Matthias

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Path MTU discovery on GRE interfaces

[Matthias May via dev]

Hi Jesse, Hi List

I'm currently fighting with issues where TCP/UDP frames that are larger than 
the MTU of a GRE tunnel are dropped.
I'm aware of the whys and how to work around the issue, but while looking for 
solutions i stumbled over the fact that:
* [1] added PMTUD support to OVS
* [2] disabled/removed with v1.9.0 respectively v1.10.0 the feature

Even after some significant time looking through the history i haven't found a 
reason why this was removed, just that it
was removed.

I started some preliminary work to add PMTUD support to OVS (again), but the 
fact that it was removed 8 years ago seems
to me like a red flag to not do it (again).

Could someone fluent with the OVS history from 8 years ago shed some light on 
why PMTUD support was dropped?
Any pointers to a thread on this topic?

BR
Matthias

[1] https://mail.openvswitch.org/pipermail/ovs-git/2010-March/009936.html
[2] https://www.openvswitch.org/releases/NEWS-2.15.0.txt

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] operstate of internal interface(s) when physical member operstate is down

[Matthias May via dev]

On 03/11/2020 18:13, Ben Pfaff wrote:
> On Mon, Oct 26, 2020 at 10:56:02AM +0100, Matthias May via dev wrote:
>> I'm looking for a way to replicate the behaviour of a standard bridge.
>> In a standard bridge when all members of the bridge report their
>> operstate as down, the bridge itself reports its operstate down as well.
>>
>> Is there any way to achieve this?
> 
> I don't think that OVS has this built in, but a controller could
> implement that behavior.
> 

Hi
Thank you for your response.

How could a controller do this?
I am using a semi-static ovs rule setup with my own rudimentary controller.

I know how to set the admin-state of the port down.
I haven't found a way to mark the oper-state of a port as down.

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] operstate of internal interface(s) when physical member operstate is down

[Matthias May via dev]

Hi List

I'm looking for a way to replicate the behaviour of a standard bridge.
In a standard bridge when all members of the bridge report their
operstate as down, the bridge itself reports its operstate down as well.

Is there any way to achieve this?

Thank you.

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Running wireguard tunnel in Open vSwitch

[Matthias May via dev]

On 03/07/2020 09:20, Pratik Panjwani wrote:
> Hi All,
>
> I am trying to extend my L2 network across sites using wireguard as my VPN.
> The networking internally across VMs in a site is managed using
> openvswitch. I have established the connectivity between the WG Client and
> WG server(tunnel endpoints). But when the traffic is being forwarded from
> any of the VMs via openvswitch bridges the client is not able to send
> packets to the WG server. I see the below error in tcpdump -
>
> 01:37:14.546804 ip: unknown ip 15
>
> 01:37:15.548112 ip: unknown ip 15
>
> 01:37:16.550092 ip: unknown ip 15
>
> Has anyone tried integrating openvswitch with wireguard?
> ___
> dev mailing list
> d...@openvswitch.org
> https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-dev__;!!I9LPvj3b!V6AprrftzUVZ8xNJt_rdejRaQQ_47DNBFB7O8Rk2iuzJWrv_Ecsp-dnTW-1Gdsrx5w$
>  

Hi Pratik
You're trying to extend your L2 net.
Wireguard transport L3 only.
You can achieve what you describe by running gretap over wireguard.
I did some performance tests in such a setup where i bridged the gretap
interface on the ovs-bridge.
Expect some reduction in throughput.
Make sure to increase the MTU of the involved paths/interfaces.

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Rules regression from 2.7.11 to 2.12.1

[Matthias May]

Hi
We recently updated from 2.7.11 (well 2.7.10 + patches from branch) to 2.12.1 
(again, 2.12.0 + patches from branch).
Almost everything seems to work except one rule.

On 2.7.x we had the following rule which is working.
priority=200,pkt_mark=0x8000/0x8000 
actions=move:NXM_NX_PKT_MARK[0..2]->NXM_OF_VLAN_TCI[13..15],NORMAL

The network driver we are using sets the highest skb-mark bit and some priority 
in the lowest 3 bits.
We need to move this priority in the skb-mark to the vlan priority.

The resulting dp entry look like this for a frame with priority 5):
recirc_id(0),in_port(7),skb_mark(0x8005/0x8007),eth(src=00:14:5a:02:10:1a,dst=ca:de:af:f1:37:9c),eth_type(0x0800),ipv4(frag=no),
packets:1768, bytes:173264, used:0.998s, actions:push_vlan(vid=211,pcp=5),3


Since the update to 2.12.x the resulting dp entry looks like this:
recirc_id(0),in_port(7),skb_mark(0x8005/0x8007),eth(src=00:14:5a:02:10:1a,dst=12:91:d5:1e:dd:77),eth_type(0x0800),ipv4(frag=no),
packets:19, bytes:1862, used:0.494s, actions:push_vlan(vid=211,pcp=0),3
--> The vlan priority is no longer being set.


While debugging I tested the following rules:
ovs-ofctl add-flow br0 "table=0 priority=300,pkt_mark=0x8000/0x8000 
actions=resubmit(,4),resubmit(,5),NORMAL"
ovs-ofctl add-flow br0 "table=4 
priority=10,actions=move:NXM_NX_PKT_MARK[0..2]->NXM_NX_REG4[0..2]"
ovs-ofctl add-flow br0 "table=5 priority=10,reg4=0,actions=mod_vlan_pcp(0)"
ovs-ofctl add-flow br0 "table=5 priority=11,reg4=1,actions=mod_vlan_pcp(1)"
ovs-ofctl add-flow br0 "table=5 priority=12,reg4=2,actions=mod_vlan_pcp(2)"
ovs-ofctl add-flow br0 "table=5 priority=13,reg4=3,actions=mod_vlan_pcp(3)"
ovs-ofctl add-flow br0 "table=5 priority=14,reg4=4,actions=mod_vlan_pcp(4)"
ovs-ofctl add-flow br0 "table=5 priority=15,reg4=5,actions=mod_vlan_pcp(5)"
ovs-ofctl add-flow br0 "table=5 priority=16,reg4=6,actions=mod_vlan_pcp(6)"
ovs-ofctl add-flow br0 "table=5 priority=17,reg4=7,actions=mod_vlan_pcp(7)"

With these rules in place, I get back the original behaviour.


Before i start digging/bisecting.
Is the action move:NXM_NX_PKT_MARK[0..2]->NXM_OF_VLAN_TCI[13..15] even expected 
to work?
Or was i abusing a bug in 2.7.x and this was never supposed to be used?

Thank you for any responses.

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] rstp: add ability to receive VLAN-tagged BPDUs

[Matthias May via dev]

On 23/02/2019 00:12, Ben Pfaff wrote:
> On Fri, Feb 15, 2019 at 12:16:14AM +0100, Matthias May via dev wrote:
>> There are switches which allow to transmit their BPDUs VLAN-tagged.
>> With this change OVS is able to receive VLAN-tagged BPDUs, but still
>> transmits its own BPDUs untagged.
>> This was tested against Westermo RFI-207-F4G-T3G.
>>
>> v2: Send patch to different address of mailing list according to suggestion
>> of Flavio Leitner.
>>
>> Signed-off-by: Matthias May 
> 
> I applied this to master.  Thanks!
> 
> I fussed with it a bit to make it closer to the preferred style.  Here
> is what I committed:
> 
> --8<----------cut here-->8--
> 
> From: Matthias May 
> Date: Fri, 15 Feb 2019 00:16:14 +0100
> Subject: [PATCH] rstp: add ability to receive VLAN-tagged BPDUs
> 
> There are switches which allow to transmit their BPDUs VLAN-tagged.
> With this change OVS is able to receive VLAN-tagged BPDUs, but still
> transmits its own BPDUs untagged.
> This was tested against Westermo RFI-207-F4G-T3G.
> 
> Signed-off-by: Matthias May 
> Signed-off-by: Ben Pfaff 
> ---
>  ofproto/ofproto-dpif-xlate.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
> index acd4817c2549..81b72be37eb5 100644
> --- a/ofproto/ofproto-dpif-xlate.c
> +++ b/ofproto/ofproto-dpif-xlate.c
> @@ -1787,7 +1787,11 @@ rstp_process_packet(const struct xport *xport, const 
> struct dp_packet *packet)
>  dp_packet_set_size(, ntohs(eth->eth_type) + ETH_HEADER_LEN);
>  }
>  
> -if (dp_packet_try_pull(, ETH_HEADER_LEN + LLC_HEADER_LEN)) {
> +int len = ETH_HEADER_LEN + LLC_HEADER_LEN;
> +if (eth->eth_type == htons(ETH_TYPE_VLAN)) {
> +len += VLAN_HEADER_LEN;
> +}
> +if (dp_packet_try_pull(, len)) {
>  rstp_port_received_bpdu(xport->rstp_port, dp_packet_data(),
>  dp_packet_size());
>  }
> 

OK.
Thank you.

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] rstp: add ability to receive VLAN-tagged BPDUs

[Matthias May via dev]

On 15/02/2019 01:28, Ben Pfaff wrote:
> On Fri, Feb 15, 2019 at 12:27:11AM +0100, Matthias May wrote:
>> On 14/02/2019 20:17, Ben Pfaff wrote:
>>> On Thu, Feb 14, 2019 at 10:58:48AM +0100, Matthias May via dev wrote:
>>>> There are switches which allow to transmit their BPDUs VLAN-tagged.
>>>> With this change OVS is able to receive VLAN-tagged BPDUs, but still
>>>> transmits its own BPDUs untagged.
>>>> This was tested against Westermo RFI-207-F4G-T3G.
>>>>
>>>> Signed-off-by: Matthias May 
>>>
>>> Thanks for the patch.
>>>
>>> To me, it seems really odd to treat packets with and without an
>>> arbitrary VLAN header the same way.  I could see it if the VLAN header
>>> had VID 0 or 1 or some other specified value, but it seems unusual to
>>> ignore it entirely.  Is this standardized or a de facto standard of some
>>> kind?
>>>
>>
>> I totally agree.
>> To me a VLAN header has nothing lost on a BPDU of a (R)STP frame, simply
>> because (R)STP is not per VLAN.
>>
>> However the fact is that there are switches which are transmitting
>> frames on a VLAN.
>>
>> With this change we simply ignore the VLAN header if is present. The
>> meaning of the BPDU doesn't cheange. The provided information still is
>> not per VLAN and applies to all ports the same.
>>
>> This patch does not add the ability to transmit VLAN tagged BPDUs for
>> the same reasoning above: RSTP/STP is not supposed to be per VLAN.
>> I was thinking about adding to the patch that one can specify a VLAN via
>> config and only BPDUs with the configured VLAN are accepted. I guess
>> this is what you propose: only accept vlan tagged BPDUs on a specified VLAN.
>> Having such a config-parameter would also enable to transmit the BPDUs
>> VLAN tagged. But I'm still of the opinion that this only suggests that
>> one could have an (R)STP tree per VLAN.
> 
> I see we are basically in agreement, but I'd like more information, if
> you have it.
> 
> Do the switches that transmit RSTP on a VLAN transmit it on a particular
> VLAN like 0 or 1?  (Maybe they are transmitting them as priority-tagged
> frames for some reason?)  If so, then it would be possible to accept
> just that VLAN.
> 

Hi Ben
The switch I tested against has config options to specify with which VLAN the 
BPDUs should be transmitted.
>From the tests I did, for this switch it doesn't matter if the received BPDUs 
>are tagged or not. The VLAN header is
simply ignored.
I have an open question with the vendor regarding this.

I did some digging on the net how other switches handle this. E.g at [1].
>From what I get, switches which allow tagged BPDUs simply ignore the header.

I started reading the 802.1d-2004 and 802.1q-2018, but so far haven't found 
anything which specifies how this situation
should be handled.

BR
Matthias


[1]
https://community.extremenetworks.com/extremeswitching-eos-230140/what-happens-if-an-s-series-receives-tagged-rstp-bpdus-7765211
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] rstp: add ability to receive VLAN-tagged BPDUs

[Matthias May via dev]

On 14/02/2019 16:51, Ben Pfaff wrote:
> On Thu, Feb 14, 2019 at 03:14:26PM +0100, Matthias May wrote:
>> On 14/02/2019 14:34, Flavio Leitner wrote:
>>>
>>> Hi Ben,
>>>
>>> This is another patch with From: field altered to be
>>> ovs-dev@openvswitch.org.
>>>
>>> [...]
>>>   From: Matthias May via dev 
>>>   Reply-To: Matthias May 
>>>
>>> If the patch gets applied as is, the commit's Author will have the
>>> wrong email.
>>>
>>> Just FYI because before Sriharsha and Neal had the same issue and we
>>> haven't identified the root cause back then.
>>>
>>> Matthias, could you describe to where exactly you sent out the
>>> patch? ovs-dev@openvswitch.org or d...@openvswitch.org or something
>>> else?
>>>
>>> Thanks,
>>> fbl
>>>
>>>
>> *thread snipped*
>> Maybe this is related to the SRS settings on mailman.
>> Looks to me a bit like "munge" is used instead of "wrap".
> 
> I guess that you're talking about the mailman setting for "from_is_list
> (general): Replace the From: header address with the list's posting
> address to mitigate issues stemming from the original From: domain's
> DMARC or similar policies."
> 
> This is set to "no", to avoid changing From: addresses at all.
> 

Hi Flavio, Ben

Sending the mail via dev instead of ovs-dev didn't seem to make a difference.

I looked at the DMARC entry of neratec.com
https://mxtoolbox.com/SuperTool.aspx?action=dmarc%3aneratec.com=toolpage
The policy is set to quarantine.

I went back in the archive and checked the other occurrences of the "Author 
should not be mailing list".
All of the domains involved have their policy set to "quarantine". So I guess 
this is the root cause.

I seems that the used mailman is on version 2.1.12
According to https://wiki.list.org/DEV/DMARC starting with 2.1.16/18 there are 
more options to handle this.

Maybe it's time to update?

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] rstp: add ability to receive VLAN-tagged BPDUs

[Matthias May via dev]

On 14/02/2019 20:17, Ben Pfaff wrote:
> On Thu, Feb 14, 2019 at 10:58:48AM +0100, Matthias May via dev wrote:
>> There are switches which allow to transmit their BPDUs VLAN-tagged.
>> With this change OVS is able to receive VLAN-tagged BPDUs, but still
>> transmits its own BPDUs untagged.
>> This was tested against Westermo RFI-207-F4G-T3G.
>>
>> Signed-off-by: Matthias May 
> 
> Thanks for the patch.
> 
> To me, it seems really odd to treat packets with and without an
> arbitrary VLAN header the same way.  I could see it if the VLAN header
> had VID 0 or 1 or some other specified value, but it seems unusual to
> ignore it entirely.  Is this standardized or a de facto standard of some
> kind?
> 

I totally agree.
To me a VLAN header has nothing lost on a BPDU of a (R)STP frame, simply
because (R)STP is not per VLAN.

However the fact is that there are switches which are transmitting
frames on a VLAN.

With this change we simply ignore the VLAN header if is present. The
meaning of the BPDU doesn't cheange. The provided information still is
not per VLAN and applies to all ports the same.

This patch does not add the ability to transmit VLAN tagged BPDUs for
the same reasoning above: RSTP/STP is not supposed to be per VLAN.
I was thinking about adding to the patch that one can specify a VLAN via
config and only BPDUs with the configured VLAN are accepted. I guess
this is what you propose: only accept vlan tagged BPDUs on a specified VLAN.
Having such a config-parameter would also enable to transmit the BPDUs
VLAN tagged. But I'm still of the opinion that this only suggests that
one could have an (R)STP tree per VLAN.

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v2] rstp: add ability to receive VLAN-tagged BPDUs

[Matthias May via dev]

There are switches which allow to transmit their BPDUs VLAN-tagged.
With this change OVS is able to receive VLAN-tagged BPDUs, but still
transmits its own BPDUs untagged.
This was tested against Westermo RFI-207-F4G-T3G.

v2: Send patch to different address of mailing list according to suggestion
of Flavio Leitner.

Signed-off-by: Matthias May 
---
 ofproto/ofproto-dpif-xlate.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index acd4817c2..7830fee2e 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1771,9 +1771,12 @@ xport_rstp_should_manage_bpdu(const struct xport *xport)
 return rstp_should_manage_bpdu(xport_get_rstp_port_state(xport));
 }
 
+#define LEN_WITHOUT_VLAN (ETH_HEADER_LEN + LLC_HEADER_LEN)
+#define LEN_WITH_VLAN (VLAN_HEADER_LEN + LEN_WITHOUT_VLAN)
 static void
 rstp_process_packet(const struct xport *xport, const struct dp_packet *packet)
 {
+int len;
 struct dp_packet payload = *packet;
 struct eth_header *eth = dp_packet_data();
 
@@ -1787,7 +1790,9 @@ rstp_process_packet(const struct xport *xport, const 
struct dp_packet *packet)
 dp_packet_set_size(, ntohs(eth->eth_type) + ETH_HEADER_LEN);
 }
 
-if (dp_packet_try_pull(, ETH_HEADER_LEN + LLC_HEADER_LEN)) {
+/* Pull a bit less payload when the BPDU is enveloped in a VLAN header */
+len = (ntohs(eth->eth_type) == 0x8100) ? LEN_WITH_VLAN : LEN_WITHOUT_VLAN;
+if (dp_packet_try_pull(, len)) {
 rstp_port_received_bpdu(xport->rstp_port, dp_packet_data(),
 dp_packet_size());
 }
-- 
2.20.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] rstp: add ability to receive VLAN-tagged BPDUs

[Matthias May via dev]

On 14/02/2019 14:34, Flavio Leitner wrote:
> 
> Hi Ben,
> 
> This is another patch with From: field altered to be
> ovs-dev@openvswitch.org.
> 
> [...]
>   From: Matthias May via dev 
>   Reply-To: Matthias May 
> 
> If the patch gets applied as is, the commit's Author will have the
> wrong email.
> 
> Just FYI because before Sriharsha and Neal had the same issue and we
> haven't identified the root cause back then.
> 
> Matthias, could you describe to where exactly you sent out the
> patch? ovs-dev@openvswitch.org or d...@openvswitch.org or something
> else?
> 
> Thanks,
> fbl
> 
> 
*thread snipped*
Maybe this is related to the SRS settings on mailman.
Looks to me a bit like "munge" is used instead of "wrap".

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] rstp: add ability to receive VLAN-tagged BPDUs

[Matthias May via dev]

On 14/02/2019 14:34, Flavio Leitner wrote:
> 
> Hi Ben,
> 
> This is another patch with From: field altered to be
> ovs-dev@openvswitch.org.
> 
> [...]
>   From: Matthias May via dev 
>   Reply-To: Matthias May 
> 
> If the patch gets applied as is, the commit's Author will have the
> wrong email.
> 
> Just FYI because before Sriharsha and Neal had the same issue and we
> haven't identified the root cause back then.
> 
> Matthias, could you describe to where exactly you sent out the
> patch? ovs-dev@openvswitch.org or d...@openvswitch.org or something
> else?
> 
> Thanks,
> fbl
> 
> 
> On Thu, Feb 14, 2019 at 12:18:11PM +0100, Matthias May via dev wrote:
>> On 14/02/2019 11:59, 0-day Robot wrote:
>>> Bleep bloop.  Greetings Matthias May via dev, I am a robot and I have tried 
>>> out your patch.
>>> Thanks for your contribution.
>>>
>>> I encountered some error that I wasn't expecting.  See the details below.
>>>
>>>
>>> checkpatch:
>>> ERROR: Author should not be mailing list.
>>> Lines checked: 47, Warnings: 0, Errors: 1
>>>
>>>
>>> Please check this out.  If you feel there has been an error, please email 
>>> acon...@bytheb.org
>>>
>>> Thanks,
>>> 0-day Robot
>>> ___
>>> dev mailing list
>>> d...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
>>
>> What is this supposed to mean?
>> Is the Signed-off-by not enough?
>>
>> BR
>> Matthias
>> ___
>> dev mailing list
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> 

Hi Flavio

Some info:
* git version 2.20.1
* (Reproduced) trace of what I entered:
```
maym@CHD500279:~/git/ovs$ git send-email send-email/ --no-chain-reply
send-email/0001-rstp-add-ability-to-receive-VLAN-tagged-BPDUs.patch
To whom should the emails be sent (if anyone)? ovs-dev@openvswitch.org

Message-ID to be used as In-Reply-To for the first email (if any)?

(mbox) Adding cc: Matthias May  from line 'From: 
Matthias May '
(body) Adding cc: Matthias May  from line 
'Signed-off-by: Matthias May '

From: Matthias May 
To: ovs-dev@openvswitch.org
Cc: Matthias May 
Subject: [PATCH] rstp: add ability to receive VLAN-tagged BPDUs
Date: Thu, 14 Feb 2019 15:01:34 +0100
Message-Id: <20190214140134.16754-1-matthias@neratec.com>
X-Mailer: git-send-email 2.20.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

The Cc list above has been expanded by additional
addresses found in the patch commit message. By default
send-email prompts before sending whenever this occurs.
This behavior is controlled by the sendemail.confirm
configuration setting.

For additional information, run 'git send-email --help'.
To retain the current behavior, but squelch this message,
run 'git config --global sendemail.confirm auto'.

Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll): y

```

This obviously has a different Message-Id then the mail sent before.

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] rstp: add ability to receive VLAN-tagged BPDUs

[Matthias May via dev]

On 14/02/2019 11:59, 0-day Robot wrote:
> Bleep bloop.  Greetings Matthias May via dev, I am a robot and I have tried 
> out your patch.
> Thanks for your contribution.
> 
> I encountered some error that I wasn't expecting.  See the details below.
> 
> 
> checkpatch:
> ERROR: Author should not be mailing list.
> Lines checked: 47, Warnings: 0, Errors: 1
> 
> 
> Please check this out.  If you feel there has been an error, please email 
> acon...@bytheb.org
> 
> Thanks,
> 0-day Robot
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> 

What is this supposed to mean?
Is the Signed-off-by not enough?

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] rstp: add ability to receive VLAN-tagged BPDUs

[Matthias May via dev]

There are switches which allow to transmit their BPDUs VLAN-tagged.
With this change OVS is able to receive VLAN-tagged BPDUs, but still
transmits its own BPDUs untagged.
This was tested against Westermo RFI-207-F4G-T3G.

Signed-off-by: Matthias May 
---
 ofproto/ofproto-dpif-xlate.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index acd4817c2..7830fee2e 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -1771,9 +1771,12 @@ xport_rstp_should_manage_bpdu(const struct xport *xport)
 return rstp_should_manage_bpdu(xport_get_rstp_port_state(xport));
 }
 
+#define LEN_WITHOUT_VLAN (ETH_HEADER_LEN + LLC_HEADER_LEN)
+#define LEN_WITH_VLAN (VLAN_HEADER_LEN + LEN_WITHOUT_VLAN)
 static void
 rstp_process_packet(const struct xport *xport, const struct dp_packet *packet)
 {
+int len;
 struct dp_packet payload = *packet;
 struct eth_header *eth = dp_packet_data();
 
@@ -1787,7 +1790,9 @@ rstp_process_packet(const struct xport *xport, const 
struct dp_packet *packet)
 dp_packet_set_size(, ntohs(eth->eth_type) + ETH_HEADER_LEN);
 }
 
-if (dp_packet_try_pull(, ETH_HEADER_LEN + LLC_HEADER_LEN)) {
+/* Pull a bit less payload when the BPDU is enveloped in a VLAN header */
+len = (ntohs(eth->eth_type) == 0x8100) ? LEN_WITH_VLAN : LEN_WITHOUT_VLAN;
+if (dp_packet_try_pull(, len)) {
 rstp_port_received_bpdu(xport->rstp_port, dp_packet_data(),
 dp_packet_size());
 }
-- 
2.20.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC] [PATCH 0/6] Add port_group to prevent loopback between interfaces

[Matthias May]

On 02/05/17 11:20, Matthias May wrote:
> On 22/04/17 03:45, Ben Pfaff wrote:
>> On Mon, Apr 03, 2017 at 11:40:54AM +0200, Matthias May wrote:
>>> When using openvswitch in combination with a hardware switch attached via 
>>> dsa
>>> it may be desirable to prevent frames from being looped back to interfaces
>>> which reside on the same switch and are already processed by the
>>> switching fabric in hardware.
>>> This patch series achieves this by introducing a new parameter port_group to
>>> be used by the normal action.
>>> When the port_group is not set explicitly, it defaults to the ofp number.
>>> Ports which are in the same group will not forward a frame between each 
>>> other.
>>
>> Thank you for proposing (and implementing) a new feature!  It's always
>> great to see new people and companies coming into the Open vSwitch
>> development community.  I'll take a more detailed look at each patch,
>> but I have a few general questions here too.
>>
>> What's dsa?
>>
>> How is this feature related to LACP?
>>
>> I guess that the answers to these questions should go in the
>> documentation as well as in the thread here.
>>
>> It looks like these patches depend on each other, so that if only some
>> of them are applied, in some cases the system does not build.  The OVS
>> philosophy is that each patch should be self-contained, so that after
>> each one is applied (in order) the system builds, works, is
>> self-consistent, and is completely documented.  I am not sure yet
>> because I have not finished review, but it seems likely that this new
>> feature should be a single patch.
>>
>> Thanks again!
>>
>> Ben.
>>
> 
> Hi Ben
> 
> Sorry for the delay...
> Thank you for your feedback.
> 
> dsa is the "distributed switch architecture" implemented mostly by marvell 
> switch chips (see [1]).
> 
> It is not related to LACP at all.
> When I started with this, I first thought I could use/reuse the LACP code but 
> I didn't see how.
> We have sprint panning tomorrow and I will see that I get some time to work 
> on this.
> I will send a v2 rebased on HEAD with your feedback integrated and 
> more/better explanation.
> 
> BR
> Matthias
> 
> 
> [1] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> 

Having found some time to work on this, I stumbled by chance over the
optional parameter "protected" described in
http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.html

This does exactly what I need and thus makes the whole patch unnecessary.

This feature isn't really announced anywhere else.
Would it make sense to patch .../utilities/ovs-vsctl.8 and describe how to use 
this there?

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] offset of 0x10001 in dpif_netlink_queue_to_priority

[Matthias May]

On 06/07/17 17:25, Ben Pfaff wrote:
> On Thu, Jul 06, 2017 at 08:39:21AM +0200, Matthias May wrote:
>> On 06/07/17 02:24, Ben Pfaff wrote:
>>> On Tue, Jul 04, 2017 at 05:09:21PM +0200, Matthias May wrote:
>>>> Hi
>>>>
>>>> I'm trying to map the vlan_pcp onto 802.11 tid.
>>>>
>>>> net/wireless/util.c in mac80211 specifies:
>>>>
>>>>>   /* skb->priority values from 256->263 are magic values to
>>>>>* directly indicate a specific 802.1d priority.  This is used
>>>>>* to allow 802.1d priority to be passed directly in from VLAN
>>>>>* tags, etc.
>>>>>*/
>>>>>   if (skb->priority >= 256 && skb->priority <= 263)
>>>>>   return skb->priority - 256;
>>>>
>>>> However the function dpif_netlink_queue_to_priority in /lib/dpif-netlink.c 
>>>> sets:
>>>>>if (queue_id < 0xf000) {
>>>>>*priority = TC_H_MAKE(1 << 16, queue_id + 1);
>>>>
>>>> With this the lowest skb_priority I can set is 0x10001, slightly over the 
>>>> magic values I need to use ;)
>>>>
>>>> Why is this offset of 0x1 + 1 in place?
>>>> Is something else in ovs about which I'm not aware dependant on this 
>>>> offset?
>>>
>>> It's because this is mapping from an OpenFlow queue ID to a kernel
>>> skb_priority value.  These aren't the same namespace and so you need a
>>> mapping function.
>>>
>>
>> What do you mean "not the same namespace"?
>> I need to set the skb_priority, set_queue sets the skb_priority but with an 
>> offset.
> 
> OpenFlow queue IDs aren't kernel skb_priorities.  They never have been.
> There is a mapping function.
> 
>> If I patch the line to
>> *priority = queue_id;
>> everything works as I expect it.
> 
> Good for you.  You just broke every existing user.
> 

Yes I am aware that the queue_id isn't the same as the skb_priority.
Please tell me:
Is my assumption wrong that using set_queue in the end results with an 
skb_priority being set?

You keep mentioning that a mapping function is there.
Isn't that what dpif_netlink_queue_to_priority is? mapping queue_id to 
skb_priority?

What breaks with this patch?
--> My original question: what is dependant on the skb_priority being offset 
with 0x10001.


What is see is with the rule:
ovs-ofctl add-flow br0 "table=0 priority=1 actions=set_queue:0x100, normal"

results without the patch in:
root@RM1:~# ovs-dpctl dump-flows
recirc_id(0),skb_priority(0),in_port(7),eth(src=02:b3:32:ba:be:02,dst=00:0e:0c:64:cc:33),eth_type(0x0800),ipv4(frag=no),
packets:11, bytes:1078, used:0.225s, actions:set(skb_priority(0x10101)),3

and with the patch in:
root@RM1:~# ovs-dpctl dump-flows
recirc_id(0),skb_priority(0),in_port(7),eth(src=02:b3:32:ba:be:02,dst=00:0e:0c:64:cc:33),eth_type(0x0800),ipv4(frag=no),
packets:49938, bytes:4893924, used:0.124s, actions:set(skb_priority(0x00100)),3

The difference being
actions:set(skb_priority(0x10101))
vs.
actions:set(skb_priority(0x00100))

Is this not setting the skb_priority in the kernel?
Am I on a completely wrong path?


BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] offset of 0x10001 in dpif_netlink_queue_to_priority

[Matthias May]

On 06/07/17 02:24, Ben Pfaff wrote:
> On Tue, Jul 04, 2017 at 05:09:21PM +0200, Matthias May wrote:
>> Hi
>>
>> I'm trying to map the vlan_pcp onto 802.11 tid.
>>
>> net/wireless/util.c in mac80211 specifies:
>>
>>> /* skb->priority values from 256->263 are magic values to
>>>  * directly indicate a specific 802.1d priority.  This is used
>>>  * to allow 802.1d priority to be passed directly in from VLAN
>>>  * tags, etc.
>>>  */
>>> if (skb->priority >= 256 && skb->priority <= 263)
>>> return skb->priority - 256;
>>
>> However the function dpif_netlink_queue_to_priority in /lib/dpif-netlink.c 
>> sets:
>>>if (queue_id < 0xf000) {
>>>*priority = TC_H_MAKE(1 << 16, queue_id + 1);
>>
>> With this the lowest skb_priority I can set is 0x10001, slightly over the 
>> magic values I need to use ;)
>>
>> Why is this offset of 0x1 + 1 in place?
>> Is something else in ovs about which I'm not aware dependant on this offset?
> 
> It's because this is mapping from an OpenFlow queue ID to a kernel
> skb_priority value.  These aren't the same namespace and so you need a
> mapping function.
> 

What do you mean "not the same namespace"?
I need to set the skb_priority, set_queue sets the skb_priority but with an 
offset.
If I patch the line to
*priority = queue_id;
everything works as I expect it.

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] offset of 0x10001 in dpif_netlink_queue_to_priority

[Matthias May]

Hi

I'm trying to map the vlan_pcp onto 802.11 tid.

net/wireless/util.c in mac80211 specifies:

>   /* skb->priority values from 256->263 are magic values to
>* directly indicate a specific 802.1d priority.  This is used
>* to allow 802.1d priority to be passed directly in from VLAN
>* tags, etc.
>*/
>   if (skb->priority >= 256 && skb->priority <= 263)
>   return skb->priority - 256;

However the function dpif_netlink_queue_to_priority in /lib/dpif-netlink.c sets:
>if (queue_id < 0xf000) {
>*priority = TC_H_MAKE(1 << 16, queue_id + 1);

With this the lowest skb_priority I can set is 0x10001, slightly over the magic 
values I need to use ;)

Why is this offset of 0x1 + 1 in place?
Is something else in ovs about which I'm not aware dependant on this offset?

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3] Replace most uses of and references to "ifconfig" by "ip".

[Matthias May]

On 27/05/17 04:29, Hunt Xu wrote:
> On Fri, May 26, 2017 at 11:46 PM, Ben Pfaff  wrote:
>> It's becoming more common that OSes include "ip" but not "ifconfig", so
>> it's best to avoid using the latter.  This commit removes most references
>> to "ifconfig" and replaces them by "ip".  It also adds a build-time check
>> to make it harder to introduce new uses of "ifconfig".
>>
>> Signed-off-by: Ben Pfaff 
>> ---
> 
> 
> 
>> diff --git a/Documentation/faq/issues.rst b/Documentation/faq/issues.rst
>> index c60336a10569..82d0605da125 100644
>> --- a/Documentation/faq/issues.rst
>> +++ b/Documentation/faq/issues.rst
>> @@ -43,8 +43,8 @@ eth0.  Help!
>>  itself.  For example, assuming that eth0's IP address is 192.168.128.5, 
>> you
>>  could run the commands below to fix up the situation::
>>
>> -$ ifconfig eth0 0.0.0.0
>> -$ ifconfig br0 192.168.128.5
>> +$ ip addr flush dev eth0
>> +$ ip addr add 192.168.128.5 dev br0
> 
> ip addr add 192.168.128.5/24 dev br0
> 
> It seems using ifconfig without specifying any netmask the netmask/prefixlen
> will still be properly set (not diving quite deep, but strace indicates that
> this is not done by ifconfig, ifconfig don't even try to set the netmask),
> whlie using ip-address with only the address specified the prefixlen is
> always 32.
> 
> Some tests on my Ubuntu 16.04:
> 1a. ifconfig br0 192.168.128.5 -> br0 gets 192.168.128.5/24
> 1b. ip addr add 192.168.128.5 dev br0 -> br0 gets 192.168.128.5/32
> 2a. ifconfig br0 172.16.128.5 -> br0 gets 172.16.128.5/16
> 2b. ip addr add 172.16.128.5 dev br0 -> br0 gets 172.16.128.5/32
> 3a. ifconfig br0 10.0.128.5 -> br0 gets 10.0.128.5/8
> 3b. ip addr add 10.0.128.5 dev br0 -> br0 gets 10.0.128.5/32
> 
>>
*snip*

You might want to consider to add brd + to the ip command.
E.g. ip addr add 192.168.128.5/24 brd + dev br0

Without:
7: br0:  mtu 1500 qdisc noop state DOWN group default qlen 
1000
link/ether 1a:78:fe:72:9c:be brd ff:ff:ff:ff:ff:ff
inet 192.168.128.5/24 scope global br0
   valid_lft forever preferred_lft forever

With:
7: br0:  mtu 1500 qdisc noop state DOWN group default qlen 
1000
link/ether 1a:78:fe:72:9c:be brd ff:ff:ff:ff:ff:ff
inet 192.168.128.5/24 brd 192.168.128.255 scope global br0
   valid_lft forever preferred_lft forever

As you can see the broadcast address isn't set without.

I see you already posted a v4 but this comment seems more appropriate in this 
thread.

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC] [PATCH 0/6] Add port_group to prevent loopback between interfaces

[Matthias May]

On 22/04/17 03:45, Ben Pfaff wrote:
> On Mon, Apr 03, 2017 at 11:40:54AM +0200, Matthias May wrote:
>> When using openvswitch in combination with a hardware switch attached via dsa
>> it may be desirable to prevent frames from being looped back to interfaces
>> which reside on the same switch and are already processed by the
>> switching fabric in hardware.
>> This patch series achieves this by introducing a new parameter port_group to
>> be used by the normal action.
>> When the port_group is not set explicitly, it defaults to the ofp number.
>> Ports which are in the same group will not forward a frame between each 
>> other.
> 
> Thank you for proposing (and implementing) a new feature!  It's always
> great to see new people and companies coming into the Open vSwitch
> development community.  I'll take a more detailed look at each patch,
> but I have a few general questions here too.
> 
> What's dsa?
> 
> How is this feature related to LACP?
> 
> I guess that the answers to these questions should go in the
> documentation as well as in the thread here.
> 
> It looks like these patches depend on each other, so that if only some
> of them are applied, in some cases the system does not build.  The OVS
> philosophy is that each patch should be self-contained, so that after
> each one is applied (in order) the system builds, works, is
> self-consistent, and is completely documented.  I am not sure yet
> because I have not finished review, but it seems likely that this new
> feature should be a single patch.
> 
> Thanks again!
> 
> Ben.
> 

Hi Ben

Sorry for the delay...
Thank you for your feedback.

dsa is the "distributed switch architecture" implemented mostly by marvell 
switch chips (see [1]).

It is not related to LACP at all.
When I started with this, I first thought I could use/reuse the LACP code but I 
didn't see how.
We have sprint panning tomorrow and I will see that I get some time to work on 
this.
I will send a v2 rebased on HEAD with your feedback integrated and more/better 
explanation.

BR
Matthias


[1] https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC] [PATCH 0/6] Add port_group to prevent loopback between interfaces

[Matthias May]

On 03/04/17 11:40, Matthias May wrote:
> When using openvswitch in combination with a hardware switch attached via dsa
> it may be desirable to prevent frames from being looped back to interfaces
> which reside on the same switch and are already processed by the
> switching fabric in hardware.
> This patch series achieves this by introducing a new parameter port_group to
> be used by the normal action.
> When the port_group is not set explicitly, it defaults to the ofp number.
> Ports which are in the same group will not forward a frame between each other.
> 

Any comments?
Is this something someone else can use?
Reasons why it is a bad idea?

BR
Matthias

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC] [PATCH 5/6] port_group: ofproto-dpif: add port_group definition and init

[Matthias May]

Signed-off-by: Matthias May <matthias@neratec.com>
---
 ofproto/ofproto-dpif.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 523adad6f..32d7d69c5 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -93,6 +93,7 @@ struct ofbundle {
 
 /* Configuration. */
 struct ovs_list ports;  /* Contains "struct ofport"s. */
+ofp_port_t port_group;  /* Group of ports to forbid loopback */
 enum port_vlan_mode vlan_mode; /* VLAN mode */
 uint16_t qinq_ethtype;
 int vlan;   /* -1=trunk port, else a 12-bit VLAN ID. */
@@ -451,8 +452,9 @@ type_run(const char *type)
 
 HMAP_FOR_EACH (bundle, hmap_node, >bundles) {
 xlate_bundle_set(ofproto, bundle, bundle->name,
- bundle->vlan_mode, bundle->qinq_ethtype,
- bundle->vlan, bundle->trunks, bundle->cvlans,
+ bundle->port_group, bundle->vlan_mode,
+ bundle->qinq_ethtype, bundle->vlan,
+ bundle->trunks, bundle->cvlans,
  bundle->use_priority_tags,
  bundle->bond, bundle->lacp,
  bundle->floodable, bundle->protected);
@@ -2896,6 +2898,7 @@ bundle_set(struct ofproto *ofproto_, void *aux,
 bundle->name = NULL;
 
 ovs_list_init(>ports);
+bundle->port_group = 0;
 bundle->vlan_mode = PORT_VLAN_TRUNK;
 bundle->qinq_ethtype = ETH_TYPE_VLAN_8021AD;
 bundle->vlan = -1;
@@ -2957,6 +2960,12 @@ bundle_set(struct ofproto *ofproto_, void *aux,
 return EINVAL;
 }
 
+/* Set port_group */
+if (s->port_group != bundle->port_group) {
+bundle->port_group = s->port_group;
+need_flush = true;
+}
+
 /* Set VLAN tagging mode */
 if (s->vlan_mode != bundle->vlan_mode
 || s->use_priority_tags != bundle->use_priority_tags) {
-- 
2.11.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC] [PATCH 3/6] port_group: bridge: set port_group in port config

[Matthias May]

Signed-off-by: Matthias May <matthias@neratec.com>
---
 vswitchd/bridge.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 867a26d8d..316e4742e 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -966,6 +966,17 @@ port_configure(struct port *port)
 s.slaves[s.n_slaves++] = iface->ofp_port;
 }
 
+/* Get port_group. */
+if (cfg->port_group) {
+if ((*cfg->port_group > 0 && *cfg->port_group < OFPP_MAX)
+|| *cfg->port_group == OFPP_LOCAL) {
+s.port_group = (uint32_t) *cfg->port_group;
+}
+} else {
+/* On a port with multiple interfaces we default to the first. */
+s.port_group = s.slaves[0];
+}
+
 /* Get VLAN tag. */
 s.vlan = -1;
 if (cfg->tag && *cfg->tag >= 0 && *cfg->tag <= 4095) {
-- 
2.11.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC] [PATCH 4/6] port_group: ofproto: add port_group definition

[Matthias May]

Signed-off-by: Matthias May <matthias@neratec.com>
---
 ofproto/ofproto.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ofproto/ofproto.h b/ofproto/ofproto.h
index 1e48e1952..29d7cdb91 100644
--- a/ofproto/ofproto.h
+++ b/ofproto/ofproto.h
@@ -402,6 +402,7 @@ struct ofproto_bundle_settings {
 ofp_port_t *slaves; /* OpenFlow port numbers for slaves. */
 size_t n_slaves;
 
+ofp_port_t port_group;  /* Group of ports to forbid loopback */
 enum port_vlan_mode vlan_mode; /* Selects mode for vlan and trunks */
 uint16_t qinq_ethtype;
 int vlan;   /* VLAN VID, except for PORT_VLAN_TRUNK. */
-- 
2.11.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC] [PATCH 2/6] port_group: add documentation entry

[Matthias May]

Signed-off-by: Matthias May <matthias@neratec.com>
---
 vswitchd/vswitch.xml | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 14297bf9a..3a7324f5d 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -1280,6 +1280,13 @@
   bonded Port.
 
 
+
+  The group affiliation of a port. If not set this defaults to the
+  open flow port number. Valid values are 1-65279, 65534.
+  Traffic processed by the normal action will not egress on a port which
+  has the same port_group as the port on which the frame ingressed.
+
+
 
   
 In short, a VLAN (short for ``virtual LAN'') is a way to partition a
-- 
2.11.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC] [PATCH 1/6] port_group: add db definitions

[Matthias May]

Signed-off-by: Matthias May <matthias@neratec.com>
---
 vswitchd/vswitch.ovsschema | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/vswitchd/vswitch.ovsschema b/vswitchd/vswitch.ovsschema
index 19b49daf1..7ebcd0d6a 100644
--- a/vswitchd/vswitch.ovsschema
+++ b/vswitchd/vswitch.ovsschema
@@ -1,6 +1,6 @@
 {"name": "Open_vSwitch",
- "version": "7.15.0",
- "cksum": "544856471 23228",
+ "version": "7.16.0",
+ "cksum": "2597117342 23427",
  "tables": {
"Open_vSwitch": {
  "columns": {
@@ -160,6 +160,11 @@
"enum": ["set", ["trunk", "access", "native-tagged",
 "native-untagged", "dot1q-tunnel"]]},
  "min": 0, "max": 1}},
+   "port_group": {
+ "type": {"key": {"type": "integer",
+  "minInteger": 1,
+  "maxInteger": 65279},
+  "min": 0, "max": 1}},
"qos": {
  "type": {"key": {"type": "uuid",
   "refTable": "QoS"},
-- 
2.11.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC] [PATCH 0/6] Add port_group to prevent loopback between interfaces

[Matthias May]

When using openvswitch in combination with a hardware switch attached via dsa
it may be desirable to prevent frames from being looped back to interfaces
which reside on the same switch and are already processed by the
switching fabric in hardware.
This patch series achieves this by introducing a new parameter port_group to
be used by the normal action.
When the port_group is not set explicitly, it defaults to the ofp number.
Ports which are in the same group will not forward a frame between each other.

Matthias May (6):
  port_group: add db definitions
  port_group: add documentation entry
  port_group: bridge: set port_group in port config
  port_group: ofproto: add port_group definition
  port_group: ofproto-dpif: add port_group definition and init
  port_group: ofproto-dpif-xlate: implement port_group

 ofproto/ofproto-dpif-xlate.c | 53 +---
 ofproto/ofproto-dpif-xlate.h |  4 ++--
 ofproto/ofproto-dpif.c   | 13 +--
 ofproto/ofproto.h|  1 +
 vswitchd/bridge.c| 11 +
 vswitchd/vswitch.ovsschema   |  9 ++--
 vswitchd/vswitch.xml |  7 ++
 7 files changed, 79 insertions(+), 19 deletions(-)

-- 
2.11.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] control characters all over the code

[Matthias May]

On 23/03/17 16:29, Ben Pfaff wrote:
> On Thu, Mar 23, 2017 at 03:34:12PM +0100, Matthias May wrote:
>> Looking at the code with eclipse 3.8.1 I noticed that in some files
>> sometimes my formatting became broken.
>> Some digging shows that this is apparently because of the control
>> character ^L
>> A grep over the whole git repository shows that this is in quite a lot
>> of places.
>> grep -r -P "\xC" ./* | wc -l
>> 1107
>>
>> Is there any reason for why these control characters are all over the code?
> 
> These are form feeds as described in the coding style document.  Form
> feeds have been used in source code for decades, so if Eclipse can't
> handle them perhaps you should report a bug to the Eclipse folks.
> 

Ok I see. I didn't see this part about that in the coding guideline.
Thank you for pointing it out.
I just wasn't sure if it's intentional or an accident.

Reading the eclipse bugtracker, I already found the report(s) about this
issue.
I guess for now I will have to live with it ^^"

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] control characters all over the code

[Matthias May]

Hi
Looking at the code with eclipse 3.8.1 I noticed that in some files
sometimes my formatting became broken.
Some digging shows that this is apparently because of the control
character ^L
A grep over the whole git repository shows that this is in quite a lot
of places.
grep -r -P "\xC" ./* | wc -l
1107

Is there any reason for why these control characters are all over the code?

BR
Matthias
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev