The following diff fixes an issue where frag list sorting was not applied
in all cases, as it should have been.
The change just moves the line
ipf_sort(ipf_list->frag_list, ipf_list->last_inuse_idx);
with some associated indentation changes.
I have some additional private tests that found this,
Deze email nieuwsbrief werd in grafisch HTML formaat verzonden.
Als u deze tekstversie ziet, verkiest uw email programma "gewone tekst" emails.
U kan de originele nieuwsbrief online bekijken:
https://ymlpsend3.com/zND
Currently, the revalidator thread may hit segmentation fault when geneve
TLV map is updated. It is because we may store the old TLV map (struct
tun_table) in the frozen state for recirculation, and we may access the
already freed old tun_table in xlate_actions().
This patch update the logic of ge
The error message in the check for improper bridge param is de-referencing
parent from the wrong bridge. Also, the message itself had the parent and
child bridges reversed, so that got a small tweak as well.
Signed-off-by: Flavio Fernandes
---
utilities/ovs-vsctl.c | 4 ++--
1 file changed, 2 in
This test will exercise the code path in ovs-vsctl where a del-port
is attempted using the parent of a fake-bridge. It expects a message
saying that user provided the wrong bridge. Not a segfault.
Signed-off-by: Flavio Fernandes
---
tests/ovs-vsctl.at | 17 +
1 file changed, 17 i
Greetings!
I was lucky enough to spend some time having fun with OVS recently and
encountered
a bug that may be worth sharing with you.
The code path in the error case when bridge's del-port is attempted for the
parent (instead of the fake-bridge) segfaults. Here are some simple steps for
reprod
On Mon, Apr 30, 2018 at 3:27 PM, Aaron Conole wrote:
> Markos Chandras writes:
>
>> On 19/04/18 16:27, Aaron Conole wrote:
>>> From: Alan Pevec
>>>
>>> Default ownership[1] for config files is failing on an empty system:
>>> Running scriptlet: openvswitch-2.9.0-3.fc28.x86_64
>>> warning: user
From: Mark Kavanagh
Currently, jumbo frame support for OvS-DPDK is implemented by
increasing the size of mbufs within a mempool, such that each mbuf
within the pool is large enough to contain an entire jumbo frame of
a user-defined size. Typically, for each user-defined MTU,
'requested_mtu', a ne
From: Mark Kavanagh
Currently, packets are only copied to a single segment in
the function dpdk_do_tx_copy(). This could be an issue in
the case of jumbo frames, particularly when multi-segment
mbufs are involved.
This patch calculates the number of segments needed by a
packet and copies the dat
From: Michael Qiu
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.
Co-authored-by: Mark Kavanagh
Co-authored-by: Tiago Lam
Signed-off-by: Michael Qiu
Signed-off-by: Mark Kavanagh
Signed-off-by: Tiago Lam
From: Michael Qiu
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.
Co-authored-by: Mark Kavanagh
[mark.b.kavan...@intel.com rebased]
Co-authored-by: Tiago Lam
Sig
From: Mark Kavanagh
Some functions in dp-packet assume that the data held by a dp_packet is
contiguous, and perform operations such as pointer arithmetic under that
assumption. However, with the introduction of multi-segment mbufs, where
data is non-contiguous, such assumptions are no longer poss
When a dp_packet is from a DPDK source, and it contains multi-segment
mbufs, the data_len is not equal to the packet size, pkt_len. Instead,
the data_len of each mbuf in the chain should be considered while
distributing the new (provided) size.
To account for the above dp_packet_set_size() has bee
From: Mark Kavanagh
dp_packets are created using xmalloc(); in the case of OvS-DPDK, it's
possible the the resultant mbuf portion of the dp_packet contains
random data. For some mbuf fields, specifically those related to
multi-segment mbufs and/or offload features, random values may cause
unexpec
From: Mark Kavanagh
There are numerous factors that must be considered when calculating
the size of an mbuf:
- the data portion of the mbuf must be sized in accordance With Rx
buffer alignment (typically 1024B). So, for example, in order to
successfully receive and capture a 1500B packet, mbu
Overview
This patchset introduces support for multi-segment mbufs to OvS-DPDK.
Multi-segment mbufs are typically used when the size of an mbuf is
insufficient to contain the entirety of a packet's data. Instead, the
data is split across numerous mbufs, each carrying a portion, or
'segment'
On Tue, May 01, 2018 at 12:36:06PM +, Jianbo Liu wrote:
> For tunnels, TOS ECN bits are never wildcard for the reason that they
> are always inherited. OVS will create a rewrite action if we add rule
> to modify other IP headers. But it also adds an extra ECN rewrite for
> the action because of
Hi,
I hope you are doing well.
I am delighted to share with you "THE SECRET BEHIND SUCCESSFUL SALES TEAM
MANAGEMENT".
I found this is beneficial to you & your organization.
Check: 5 Advantages of Smart Work-flow:
1. Automate work-force.
2. Increases transparency
For tunnels, TOS ECN bits are never wildcard for the reason that they
are always inherited. OVS will create a rewrite action if we add rule
to modify other IP headers. But it also adds an extra ECN rewrite for
the action because of this ECN un-wildcarding.
It seems no error because the ECN bits to
> On 04/27/2018 05:40 PM, Pablo Cascón wrote:
> > Currently to RX jumbo packets fails for NICs not supporting scatter.
> > Scatter is not strictly needed for jumbo RX support. This change fixes
> > the issue by not enabling scatter only for the PMD/NIC known not to
> > need it to support jumbo RX.
20 matches
Mail list logo
