When doing packet clone, if packet source is from DPDK driver,
multi-segment must be considered, and copy the segment's
data one by one.
Signed-off-by: Michael Qiu
Signed-off-by: Jijiang Liu
---
lib/dp-packet.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
di
Currently, one packet is only copied to one segment
in function dpdk_do_tx_copy(), this could be an issue
when a jumboframe comes, especially for multipile segments.
This patch calculate the segment number needed by the packet and
copy the data to different segments.
Signed-off-by: Michael Qiu
When a packet is from DPDK source, and it contains
multipule segments, data_len is not equal to the
packet size. This patch fix this issue.
Signed-off-by: Michael Qiu
Signed-off-by: Marcin Ksiadz
Signed-off-by: Mark Kavanagh
Signed-off-by: Przemyslaw Lal
Signed-off-by: Yuanhan Liu
---
lib/dp
Currently, when doing packet copy, lots of DPDK mbuf's info
will be missed, like packet type, ol_flags, etc.
Those information is very important for DPDK to do
packets processing.
Signed-off-by: Michael Qiu
Signed-off-by: Jijiang Liu
---
lib/dp-packet.c | 3 +++
lib/netdev-dpdk.c | 4
2
When building with DPDK, and using xmalloc() to get a new packet,
field mbuf of the packet will not be initialized, but it's very important for
DPDK port when copying the data to DPDK mbuf, because if ol_flags
and other info are random values, DPDK driver may hang.
Signed-off-by: Michael Qiu
Sign
Currently, OVS only supports DPDK single segment mbuf,
it could lead problems, like a large non-DPDK source
packet transmit to dpdk port.
Also, OVS doesn't copy enough info in mbuf when do
packet copy.
At the same time, vlan and tunnelling packet's DPDK
offloads, for example TSO, needs multi-segm
openvswitch 2.3.0+git20140819-4 is marked for autoremoval from testing on
2016-11-25
It is affected by these RC bugs:
828478: openvswitch: FTBFS with openssl 1.1.0
It (build-)depends on packages with these RC bugs:
828354: ipsec-tools: FTBFS with openssl 1.1.0
__
Hi Flavio, Daniele
I think that the idea of integrating the patch in the naming convention is
good.
I only have two comments:
- I would keep it limited to physical devices for the moment, maybe in a
future we can think about supporting other device creation arguments.
- How is the detach suppose t
Hi Flavio,
I was thinking that instead of having a separate appctl we could integrate
the attach into netdev_dpdk_construct() while changing the naming
convention, as discussed here:
http://openvswitch.org/pipermail/dev/2016-August/078113.html
What do you think?
Thanks,
Daniele
2016-10-26 11:
> On Oct 26, 2016, at 12:08 AM, Pratyushaw P/HYD/TCS
> wrote:
>
> Hello,
>
> It's a pleasure to contribute to the to the OF version 1.5 Extensions for the
> upcoming releases.
>
> We have planned and picked up few of the below Extensions from the OpenFlow
> 1.5 Specification listed:
>
>
On Wed, Oct 26, 2016 at 2:55 AM, Thadeu Lima de Souza Cascardo
wrote:
> On Tue, Oct 25, 2016 at 08:21:55PM -0700, Pravin Shelar wrote:
>> > The fallback option should already work, then. We can make sure during
>> > testing
>> > that is the case, so there would be no need to verify ovs_vxlan is p
Hi Mauricio,
Could you please rebase this patch? It doesn't apply anymore.
I will review ASAP.
Thanks!
Flavio
On Fri, Jul 15, 2016 at 04:15:31PM +0200, Mauricio Vasquez B wrote:
> In order to use dpdk ports in ovs they have to be bound to a DPDK
> compatible driver before ovs is started.
>
> T
Processing commands for cont...@bugs.debian.org:
> severity 828417 serious
Bug #828417 [src:libxr] libxr: FTBFS with openssl 1.1.0
Severity set to 'serious' from 'important'
> severity 828502 serious
Bug #828502 [src:pidgin-openfetion] pidgin-openfetion: FTBFS with openssl 1.1.0
Severity set to 's
Thanks Mark, I will check this.
I am not using multi-queue and from this thread, they have already added a
change in OVS to support older version of QEMU(queue 0 is enabled in OVS
even if qemu doesnt send VRING_ENABLE), which is what helped me to use qemu
2.4.1 till OVS 2.5.9. are these threads re
>
>Hi Mark,
>
>This commit is already part of 2.6.0 that i am using. Also, when i create an
>port with
>mtu_request, it is creating with the expected mtu, no problems here.
>
>The issue i am facing is, i am not even able to run traffic through a
>PHY-VM-PHY with the
>default MTU (mtu_request not
Hi Mark,
This commit is already part of 2.6.0 that i am using. Also, when i create
an port with mtu_request, it is creating with the expected mtu, no problems
here.
The issue i am facing is, i am not even able to run traffic through a
PHY-VM-PHY with the default MTU (mtu_request not used).
I am j
>
>Hi,
>
>Issue Setup: DPDK 16.07 + OVS 2.6.0 + qemu 2.4.1 : PHY-VM-PHY
>
>I am trying to upgrade from (DPDK16.04 + OVS2.5.9), to (DPDK16.07 + OVS2.6.0)
>for jumbo frame
>support. After the upgrade, all packets are getting dropped on the vhostuser
>port.
>The dpdk/vhost user ports used here has
Hi Ben and Xiao,
One comment below.
On Mon, Oct 17, 2016 at 11:15:28AM +0800, Xiao Liang wrote:
> Hi Ben,
>
> Please see inline.
>
> And another question:
> In datapath/README.md:
> - If the userspace flow key includes more fields than the
> kernel's, for example if userspace decoded an I
Hi,
Issue Setup: DPDK 16.07 + OVS 2.6.0 + qemu 2.4.1 : PHY-VM-PHY
I am trying to upgrade from (DPDK16.04 + OVS2.5.9), to (DPDK16.07 +
OVS2.6.0) for jumbo frame support. After the upgrade, all packets are
getting dropped on the vhostuser port.
The dpdk/vhost user ports used here has default MTU o
On Tue, Oct 18, 2016 at 4:03 PM, Stephen Finucane wrote:
> This is a top-level document, so plain old rST is preferred.
>
> Signed-off-by: Stephen Finucane
>
I made one small fix and applied this to master.
diff --git a/SECURITY.rst b/SECURITY.rst
index 31155a5..5061e53 100644
--- a/SECURITY.r
On Tue, Oct 25, 2016 at 5:55 AM, Russell Bryant wrote:
>
>
> On Sun, Oct 23, 2016 at 8:00 AM, Stephen Fincane
> wrote:
>
>> On Fri, 2016-10-21 at 16:09 -0400, Russell Bryant wrote:
>> >
>> >
>> > On Tue, Oct 18, 2016 at 4:03 PM, Stephen Finucane
>> > wrote:
>> > > Signed-off-by: Stephen Finucan
On Tue, Oct 25, 2016 at 08:21:55PM -0700, Pravin Shelar wrote:
> > The fallback option should already work, then. We can make sure during
> > testing
> > that is the case, so there would be no need to verify ovs_vxlan is present
> > in
> > case 3. Would that be OK for you?
> >
> I am not sure how
Hello,
It's a pleasure to contribute to the to the OF version 1.5 Extensions for the
upcoming releases.
We have planned and picked up few of the below Extensions from the OpenFlow 1.5
Specification listed:
B.18.5 Copy-Field action to copy between two OXM fields
B.18.9 Allow set-field action
23 matches
Mail list logo
