Bleep bloop. Greetings Anju Thomas, 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.
git-am:
:804: new blank line at EOF.
+
warning: 1 line adds whitespace errors.
Failed to merge in the
From: Maciej Józefczyk
For Openstack Internal DNS functionality we need
to provide support for domain_name option.
DHCP option 15 was previously used only in parser
tests and according to RFC it should be renamed to
domain_name [1].
This patch modifies its name in the tests from
'domain' to
OVS may be unable to transmit packets for multiple reasons and
today there is a single counter to track packets dropped due to
any of those reasons. The most common reason is that a VM is
unable to read packets fast enough causing the vhostuser port
transmit queue on the OVS side to become full.
On Mon, May 27, 2019 at 10:55:52AM +0200, Dumitru Ceara wrote:
> Encap tunnel-ids are of the form:
> .
> In physical_run we were checking if a tunnel-id corresponds
> to the local chassis-id by searching if the chassis-id string
> is included in the tunnel-id (strstr). This can break quite
>
Done.
On Thu, Jun 06, 2019 at 05:55:33PM -0700, Yifeng Sun wrote:
> Hi Ben,
>
> Can you please backport this patch to 2.10, thanks.
>
> Yifeng
>
> On Thu, Aug 16, 2018 at 9:14 AM Gregory Rose wrote:
> >
> >
> > On 8/15/2018 6:24 AM, Yifeng Sun wrote:
> > > In compatable gre module, skb->cb is
On 07.06.2019 15:39, Sriram Vatala wrote:
> OVS may be unable to transmit packets for multiple reasons and
> today there is a single counter to track packets dropped due to
> any of those reasons. The most common reason is that a VM is
> unable to read packets fast enough causing the vhostuser
On Fri, Jun 07, 2019 at 02:14:28PM +0200, mjoze...@redhat.com wrote:
> From: Maciej Józefczyk
>
> For Openstack Internal DNS functionality we need
> to provide support for domain_name option.
> DHCP option 15 was previously used only in parser
> tests and according to RFC it should be renamed to
¡Hola!
Me da mucho gusto saludarte.
Es para mi un placer poder invitarte a nuestro webinar "Estrategia logística:
Aprovisionamiento y distribución" que se
estará llevando a cabo el día jueves 27 de junio con un horario de 10:00 a
17:00 hrs. (hora de la ciudad de México)
Con este curso en
On 07.06.2019 17:28, Ilya Maximets wrote:
> On 07.06.2019 15:39, Sriram Vatala wrote:
>> OVS may be unable to transmit packets for multiple reasons and
>> today there is a single counter to track packets dropped due to
>> any of those reasons. The most common reason is that a VM is
>> unable to
On Wed, May 29, 2019 at 08:26:12PM +0800, ychen wrote:
> hi,
>when I send IP packets with ttl in IP header is random in range(1-255),
> and with all other IP header fields stay not changed
> but generated 255 datapath flows each with different ttl value.
> of course, i use the action
On Thu, Jun 06, 2019 at 06:34:21AM +, Nitin Katiyar wrote:
>
>
> > -Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Wednesday, June 05, 2019 12:03 AM
> > To: Nitin Katiyar
> > Cc: ovs-dev@openvswitch.org; Manohar Krishnappa Chidambaraswamy
> >
> > Subject: Re:
Hi William,
No review or full test yet, just some observations…
We run OVS as a non root user, which is causing OVS with XDP to fail:
2019-06-07T09:14:20.628Z|00023|ofproto_dpif|INFO|netdev@ovs-netdev:
Datapath supports ct_orig_tuple
The OpenFlow specification says that buckets in select groups with a weight
of zero should not be selected, but the ofproto-dpif implementation could
select them in corner cases. This fixes the problem.
Reported-by: ychen
Reported-at:
On Wed, Jun 05, 2019 at 03:35:34PM -0700, Darrell Ball wrote:
> From: solomon
>
> ICMP/ICMPv6 fails, if the src/dst port is set in a common NAT rule.
> For example:
> actions=ct(nat(dst=172.16.1.100:5000),commit,table=40)
>
> Fixes: 4cd0481c9e8b ("conntrack: Fix wasted work for ICMP NAT.")
>
On Fri, May 24, 2019 at 01:32:42PM -0700, Yi-Hung Wei wrote:
> On Fri, May 24, 2019 at 11:24 AM Yifeng Sun wrote:
> >
> > 4.9.172+ kernel backported upstream patch 70b095c843266
> > ("ipv6: remove dependency of nf_defrag_ipv6 on ipv6 module")
> > and this caused compilation errors of OVS kernel
Signed-off-by: Ben Pfaff
---
ofproto/ofproto-dpif-xlate.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 04d69ed06c20..ea72eedb1cde 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++
Hi Eelco,
Thanks for the testing.
On Fri, Jun 7, 2019 at 8:43 AM Eelco Chaudron wrote:
>
> Hi William,
>
> No review or full test yet, just some observations…
>
> We run OVS as a non root user, which is causing OVS with XDP to fail:
Right, XDP requires using root privilege.
I will add this in
On Wed, May 29, 2019 at 09:54:04AM +, Anju Thomas wrote:
> As part of in-band control, OVS is expected to send DHCP server replies to
> the LOCAL port as well. In this case, OVS implicitly adds an additional
> action to output to the bridge’s LOCAL port after the ofproto translation for
>
Bleep bloop. Greetings Ben Pfaff, 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:
WARNING: Line is 88 characters long (recommended limit is 79)
#23 FILE:
On Wed, May 22, 2019 at 01:26:03PM +0200, Dumitru Ceara wrote:
> The chassis_run code didn't take into account the scenario when the
> system-id was changed in the Open_vSwitch table. Due to this the code
> was trying to insert a new Chassis record in the OVN_Southbound DB with
> the same Encaps
On Wed, May 29, 2019 at 08:05:13PM +0800, ychen wrote:
> hi,
>I noticed that we can set bucket's weight to 0 when add/mod group.
>1. when we use default select method, and when all the buckets with weight
> larger than 0 change to dead,
> we can still pick the bucket whose weight is
On Mon, May 27, 2019 at 11:00:17AM +0200, Lorenzo Bianconi wrote:
> Do not send traffic for local FIP through the overlay tunnels but
> manage it in the local hypervisor
>
> Signed-off-by: Lorenzo Bianconi
This is one where I'd appreciate a review by someone else knowledgeable
of the context.
Bleep bloop. Greetings Ben Pfaff, 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:
WARNING: Line is 88 characters long (recommended limit is 79)
#17 FILE:
On Wed, Jun 05, 2019 at 10:36:33PM +, Van Bemmel, Jeroen (Nokia - US) wrote:
> For a series of IP fragments, only the first packet includes the transport
> header (TCP/UDP/SCTP) and the src/dst ports. By including these port
> numbers in the hash, it may happen that a first fragment hashes to
On Wed, May 15, 2019 at 12:16:42PM -0700, Han Zhou wrote:
> On Wed, May 15, 2019 at 6:34 AM Lorenzo Bianconi <
> lorenzo.bianc...@redhat.com> wrote:
> >
> > pinctrl_handle_buffered_packets can insert new elements in
> > buffered_packets_map hasmap and it runs concurrently with pinctrl_run
> >
On Mon, May 27, 2019 at 12:52:24PM +0530, nusid...@redhat.com wrote:
> If suppose the virtual_ip is configured to 10.0.0.10 on a virtual logical
> port 'sw0-vip'
> and the virtual_parents are set to - [sw0-p1, sw0-p2] then below logical
> flows are added in the
> lsp_in_arp_rsp logical switch
On 6/6/2019 10:27 PM, Anju Thomas wrote:
Currently OVS maintains explicit packet drop/error counters only on port level.
Packets that are dropped as part of normal OpenFlow processing are counted in
flow stats of “drop” flows or as table misses in table stats.
These can only be interpreted by
Weights are significant only for "select" groups;
group_first_live_bucket() is used to pick a bucket only for
"fast-failover" groups. So I think that this is correct for group
selection now.
However, group_is_alive() also uses group_first_live_bucket() for
determining whether a group is alive,
On Fri, Jun 07, 2019 at 04:27:32PM -0700, Ben Pfaff wrote:
> The OpenFlow specification says that buckets in select groups with a weight
> of zero should not be selected, but the ofproto-dpif implementation could
> select them in corner cases. This fixes the problem.
>
> Reported-by: ychen
>
Thanks, applied to master.
On Fri, Jun 07, 2019 at 03:34:04PM -0700, Yifeng Sun wrote:
> Look good to me, thanks.
>
> Reviewed-by: Yifeng Sun
>
> On Fri, Jun 7, 2019 at 1:03 PM 0-day Robot wrote:
> >
> > Bleep bloop. Greetings Ben Pfaff, I am a robot and I have tried out your
> > patch.
> >
Look good to me, thanks.
Reviewed-by: Yifeng Sun
On Fri, Jun 7, 2019 at 1:03 PM 0-day Robot wrote:
>
> Bleep bloop. Greetings Ben Pfaff, 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
Fixed a bug where checking for major version 3.10 and major revision not
equal to 327 or 693 or 957 should have gone to the default else at the end.
In the current code, the default else condition will not get executed
for kernel with major version 3.10 and major revision not equal
to 327/693/957
Thanks Ashish for the fix.
Reviewed-by: Yifeng Sun
On Fri, Jun 7, 2019 at 3:45 PM Ashish Varma wrote:
>
> Fixed a bug where checking for major version 3.10 and major revision not
> equal to 327 or 693 or 957 should have gone to the default else at the end.
> In the current code, the default
On 6/7/2019 3:39 PM, Ashish Varma wrote:
Fixed a bug where checking for major version 3.10 and major revision not
equal to 327 or 693 or 957 should have gone to the default else at the end.
In the current code, the default else condition will not get executed
for kernel with major version 3.10
The OpenFlow specification says that buckets in select groups with a weight
of zero should not be selected, but the ofproto-dpif implementation could
select them in corner cases. This fixes the problem.
Reported-by: ychen
Reported-at:
The OpenFlow specification says that buckets in select groups with a weight
of zero should not be selected, but the ofproto-dpif implementation could
select them in corner cases. This fixes the problem.
Reported-by: ychen
Reported-at:
I sent v2:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-June/359582.html
On Fri, Jun 07, 2019 at 03:55:36PM -0700, Ben Pfaff wrote:
> Weights are significant only for "select" groups;
> group_first_live_bucket() is used to pick a bucket only for
> "fast-failover" groups. So I think that
On 6/7/2019 2:31 PM, Gregory Rose wrote:
On 6/6/2019 10:27 PM, Anju Thomas wrote:
Currently OVS maintains explicit packet drop/error counters only on
port level.
Packets that are dropped as part of normal OpenFlow processing are
counted in flow stats of “drop” flows or as table misses in
Hi Ben,
group_first_live_bucket() can still return zero-weighted bucket, then
this bucket will
be used via pick_ff_group() and xlate_group_action__(). I am wondering
if it is an
issue?
Thanks,
Yifeng
On Fri, Jun 7, 2019 at 12:04 PM 0-day Robot wrote:
>
> Bleep bloop. Greetings Ben Pfaff, I am
Hi,
When using AF_XDP, the TC qdisc layer is by-passed and packets go to
userspace directly. One problem is that there is no QoS support when
using AF_XDP.
For egress shaping, I'm thinking about using tc-mqprio, which has
hardware offload support. And for OVS, we can add tc-mqprio support.
For
> > > + ethtool -L enp2s0 combined 1
> > > + ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x10
> > > + ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0 type="afxdp"
> > > \
> > > +options:n_rxq=1 options:xdpmode=drv \
> > > +other_config:pmd-rxq-affinity="0:4"
another
41 matches
Mail list logo
