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 controllers that know the
semantics of the
On Tue, Dec 17, 2019 at 4:34 PM Ilya Maximets wrote:
>
> On 09.12.2019 21:42, William Tu wrote:
> > On Sat, Dec 07, 2019 at 03:46:18PM +0100, Ilya Maximets wrote:
> >> New file created for AF_XDP specific tests.
> >>
> >> Signed-off-by: Ilya Maximets
> > tested and LGTM, one minor comment.
> >
>
On Tue, Dec 17, 2019 at 7:51 AM Matteo Croce wrote:
>
> New action to decrement TTL instead of setting it to a fixed value.
> This action will decrement the TTL and, in case of expired TTL, drop it
> or execute an action passed via a nested attribute.
> The default TTL expired action is to drop
Bleep bloop. Greetings , 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: Unexpected sign-offs from developers who are not authors or co-authors
or committers: Ben Pfaff
Hi, William
I used OVS DPDK to test it, you shouldn't add tap interface to ovs DPDK bridge
if you use vdev to add tap, virtio_user is just for it, but that won't use this
receive function to receive packets.
At 2019-12-17 02:55:50, "William Tu" wrote:
>On Fri, Dec 06, 2019 at 02:09:24AM
From: Yi Yang
Current netdev_linux_rxq_recv_tap and netdev_linux_rxq_recv_sock
just receive single packet, that is very inefficient, per my test
case which adds two tap ports or veth ports into OVS bridge
(datapath_type=netdev) and use iperf3 to do performance test
between two ports (they are
Ben, thank for your review, for recvmmsg, we have to prepare some buffers
for it, but we have no way to know how many packets are there for socket, so
these mallocs are must-have overhead, maybe self-adaptive malloc mechanism
is better, for example, the first receive just mallocs 4 buffers, if it
On 09.12.2019 21:42, William Tu wrote:
> On Sat, Dec 07, 2019 at 03:46:18PM +0100, Ilya Maximets wrote:
>> New file created for AF_XDP specific tests.
>>
>> Signed-off-by: Ilya Maximets
> tested and LGTM, one minor comment.
>
> Acked-by: William Tu
>> ---
>> tests/automake.mk |
On 11.11.2019 15:02, Eelco Chaudron wrote:
> Currently, OVS does not register and therefore not handle the
> interface reset event from the DPDK framework. This would cause a
> problem in cases where a VF is used as an interface, and its
> configuration changes.
>
> As an example in the following
On 17.12.2019 19:39, Ilya Maximets wrote:
> On 17.12.2019 19:25, Ben Pfaff wrote:
>> On Tue, Dec 17, 2019 at 02:45:03PM +0100, Eelco Chaudron wrote:
>>>
>>>
>>> On 6 Nov 2019, at 14:32, Eelco Chaudron wrote:
>>>
On 5 Nov 2019, at 18:20, Ilya Maximets wrote:
> Sometimes interface
Bleep bloop. Greetings Yi-Hung Wei, 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 lacks whitespace around operator
#134 FILE: lib/netdev-linux.c:1419:
From: William Tu
The patch detects the numa node id from the name of the netdev,
by reading the '/sys/class/net//device/numa_node'.
If not available, ex: virtual device, or any error happens,
return numa id 0. Currently only the afxdp netdev type uses it,
other linux netdev types are disabled
Currently, the AF_XDP socket (XSK) related memory are allocated by main
thread in the main thread's NUMA domain. With the patch that detects
netdev-linux's NUMA node id, the PMD thread of AF_XDP port will be run on
the AF_XDP netdev's NUMA domain. If the net device's NUMA domain
is different
On Tue, Dec 17, 2019 at 04:51:35PM -0500, Aaron Conole wrote:
> Ben Pfaff writes:
>
> > Not every system will have recvmmsg(), so introduce compatibility code
> > that will allow it to be used blindly from the rest of the tree.
> >
> > This assumes that recvmmsg() and sendmmsg() are either both
Ben Pfaff writes:
> Not every system will have recvmmsg(), so introduce compatibility code
> that will allow it to be used blindly from the rest of the tree.
>
> This assumes that recvmmsg() and sendmmsg() are either both present or
> both absent in system libraries and headers.
>
> CC: Yi Yang
On Mon, Dec 09, 2019 at 02:26:43PM +0100, Damijan Skvarc wrote:
> Signed-off-by: Damijan Skvarc
Thanks! Applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On 17.12.2019 21:56, Eli Britstein wrote:
>
> On 12/17/2019 9:07 PM, Ilya Maximets wrote:
>> On 17.12.2019 18:38, Eli Britstein wrote:
>>> On 12/16/2019 8:47 PM, Ilya Maximets wrote:
3. New 'dp_layer' types has to be documented in dpctl man.
Also, 'in_hw' doesn't look like a
On Tue, Dec 17, 2019 at 10:26:05PM +0100, Ilya Maximets wrote:
> On 17.12.2019 20:23, Ben Pfaff wrote:
> > Is there a reason to allow users to turn this off? What is the downside
> > of enabling it? Why is it disabled by default? In general, OVS should
> > optimize itself to the extent it can
On 17.12.2019 20:23, Ben Pfaff wrote:
> Thanks for the patch!
>
> "sparse" reports some type errors:
>
> ../ofproto/bond.c:357:30: error: incorrect type in assignment (different
> base types)
> ../ofproto/bond.c:357:30:expected unsigned int
> ../ofproto/bond.c:357:30:got
On 17.12.2019 10:22, David Marchand wrote:
> On Fri, Dec 13, 2019 at 6:34 PM Ilya Maximets wrote:
>>> @@ -94,6 +99,38 @@ args_contains(const struct svec *args, const char *value)
>>> return false;
>>> }
>>>
>>> +static void
>>> +construct_dpdk_lcore_option(const struct smap
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: Comment with 'xxx' marker
#65 FILE: lib/socket-util.c:1293:
ovs_assert(!timeout);
On 12/17/2019 9:07 PM, Ilya Maximets wrote:
> On 17.12.2019 18:38, Eli Britstein wrote:
>> On 12/16/2019 8:47 PM, Ilya Maximets wrote:
>>> 3. New 'dp_layer' types has to be documented in dpctl man.
>>> Also, 'in_hw' doesn't look like a datapath layer name.
>>> Suggesting to use 'dpdk'
Not every system will have recvmmsg(), so introduce compatibility code
that will allow it to be used blindly from the rest of the tree.
This assumes that recvmmsg() and sendmmsg() are either both present or
both absent in system libraries and headers.
CC: Yi Yang
Signed-off-by: Ben Pfaff
---
I
On Fri, Dec 06, 2019 at 02:09:24AM -0500, yang_y...@163.com wrote:
> From: Yi Yang
>
> Current netdev_linux_rxq_recv_tap and netdev_linux_rxq_recv_sock
> just receive single packet, that is very inefficient, per my test
> case which adds two tap ports or veth ports into OVS bridge
>
Thanks for the patch!
"sparse" reports some type errors:
../ofproto/bond.c:357:30: error: incorrect type in assignment (different
base types)
../ofproto/bond.c:357:30:expected unsigned int
../ofproto/bond.c:357:30:got restricted ofp_port_t [usertype] ofp_port
On 17.12.2019 18:38, Eli Britstein wrote:
>
> On 12/16/2019 8:47 PM, Ilya Maximets wrote:
>> 3. New 'dp_layer' types has to be documented in dpctl man.
>> Also, 'in_hw' doesn't look like a datapath layer name.
>> Suggesting to use 'dpdk' as netdev-offload-tc uses 'tc'.
>> We also
On 17.12.2019 19:25, Ben Pfaff wrote:
> On Tue, Dec 17, 2019 at 02:45:03PM +0100, Eelco Chaudron wrote:
>>
>>
>> On 6 Nov 2019, at 14:32, Eelco Chaudron wrote:
>>
>>> On 5 Nov 2019, at 18:20, Ilya Maximets wrote:
>>>
Sometimes interface updates could happen in a way ifnotifier is not
On Tue, Dec 17, 2019 at 02:45:03PM +0100, Eelco Chaudron wrote:
>
>
> On 6 Nov 2019, at 14:32, Eelco Chaudron wrote:
>
> > On 5 Nov 2019, at 18:20, Ilya Maximets wrote:
> >
> > > Sometimes interface updates could happen in a way ifnotifier is not
> > > able to catch. For example some heavy
On 12/16/2019 8:47 PM, Ilya Maximets wrote:
> 3. New 'dp_layer' types has to be documented in dpctl man.
> Also, 'in_hw' doesn't look like a datapath layer name.
> Suggesting to use 'dpdk' as netdev-offload-tc uses 'tc'.
> We also could return specific dp_layer for partially offloaded
Would appreciate any thoughts on this.
thanks,
-venu
On Tuesday, November 19, 2019, 12:40:47 PM PST,
wrote:
From: venu iyer
If one creates a port group and a MAC address set, and an
ACL that prevents packets being output to a port in that Port Group from
any MAC address in that
>
> In function internal_dev_recv, currently it calls
> netif_rx(skb)
> and this skips the generic xdp code path.
>
> I wonder if it's ok to replace netif_rx with
> netif_receive_skb(skb)
> Then the generic xdp should work.
>
> Ohh, interesting, I'll check that !
cheers,
Nick
>
>
> because internal port is a loopback device, and packet
> does not go through linux tc qdisc. So the attached ebpf
> program through tc does not work.
> Attach XDP program also does not work.
>
Oh I see !
> May I know your use case?
>
I'd like to attach an ebpf program to rate limit
On 17/12/2019 17:51, Matteo Croce wrote:
> New action to decrement TTL instead of setting it to a fixed value.
> This action will decrement the TTL and, in case of expired TTL, drop it
> or execute an action passed via a nested attribute.
> The default TTL expired action is to drop the packet.
>
On Tue, Dec 17, 2019 at 07:59:42AM -0800, William Tu wrote:
> On Tue, Dec 17, 2019 at 09:14:00AM -0500, Nicolas Bouliane wrote:
> > >
> > >
> > > type of this port?
> > >
> > Internal
> >
> > We need to have an IP address set on the interface, which is why we use the
> > internal type.
> >
> >
On Tue, Dec 17, 2019 at 11:03 AM Vishal Deep Ajmera
wrote:
>
> Problem:
>
> In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
> (using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
> "HASH" and "RECIRC" datapath actions. After recirculation,
On Tue, Dec 17, 2019 at 09:14:00AM -0500, Nicolas Bouliane wrote:
> >
> >
> > type of this port?
> >
> Internal
>
> We need to have an IP address set on the interface, which is why we use the
> internal type.
>
>
> > Can you share your "ovs-vsctl show"
> > If meta0 is "type: internal", then it
New action to decrement TTL instead of setting it to a fixed value.
This action will decrement the TTL and, in case of expired TTL, drop it
or execute an action passed via a nested attribute.
The default TTL expired action is to drop the packet.
Supports both IPv4 and IPv6 via the ttl and
Accessing the sw stats in the vhost datapath of a PVP test
can incur a performance drop of ~2%.
Most of the time these stats will just be getting zero added
to them. By checking if there is a non-zero update first, we
can avoid accessing them when they won't be updated and avoid
the performance
On Fri, Dec 13, 2019 at 9:16 PM wrote:
>
> From: Numan Siddique
>
> When ovsdb-server is in backup mode and connects to the active
> ovsdb-server for replication, and if takes more than 5 seconds to
> get the dump of the whole database, it will drop the connection
> soon after as the default
>
>
> type of this port?
>
Internal
We need to have an IP address set on the interface, which is why we use the
internal type.
> Can you share your "ovs-vsctl show"
> If meta0 is "type: internal", then it doesn't work.
>
Port "meta0"
Interface "meta0"
type:
Any comments on this patch? Guess it might be waiting for “[PATCH]
bridge: Allow manual notifications about interfaces”.
Would like to get this ready for 2.13…
Cheers,
Eelco
On 11 Nov 2019, at 15:02, Eelco Chaudron wrote:
Currently, OVS does not register and therefore not handle the
On 6 Nov 2019, at 14:32, Eelco Chaudron wrote:
On 5 Nov 2019, at 18:20, Ilya Maximets wrote:
Sometimes interface updates could happen in a way ifnotifier is not
able to catch. For example some heavy operations (device reset) in
netdev-dpdk could require re-applying of the bridge
v7->v8:
Removed hash action for balance-tcp mode.
Removed bond-only pmd reload action.
Rebased to OVS master.
v6->v7:
Fixed issue reported by Matteo for bond/show.
v5->v6:
Addressed comments from Ilya Maximets.
https://mail.openvswitch.org/pipermail/ovs-dev/2019-August/362001.html
Rebased
Problem:
In OVS-DPDK, flows with output over a bond interface of type “balance-tcp”
(using a hash on TCP/UDP 5-tuple) get translated by the ofproto layer into
"HASH" and "RECIRC" datapath actions. After recirculation, the packet is
forwarded to the bond member port based on 8-bits of the
On Fri, Dec 13, 2019 at 6:34 PM Ilya Maximets wrote:
> > @@ -94,6 +99,38 @@ args_contains(const struct svec *args, const char *value)
> > return false;
> > }
> >
> > +static void
> > +construct_dpdk_lcore_option(const struct smap *ovs_other_config,
> > +struct
I have no problem, maybe remove the changelog part?
paulb@reg-r-vrt-019-180 openvswitch (git (detached from origin/master))$ git
checkout FETCH_HEAD
Note: checking out 'FETCH_HEAD'.
paulb@reg-r-vrt-019-180 openvswitch (git (detached from origin/master))$ git am
46 matches
Mail list logo
