Hi Flavio,
to follow up on this: I have just upgraded DPDK to 18.11 and OVS to 2.11 and I
don't see this issue anymore. Also, I don't observe any "ring error" messages
although the MTU is still at 9216 and OvS only has 1Gb of memory.
Do you have an idea which change in DPDK/OvS might have resolved it?
Thanks
Tobias
On 06.11.19, 14:44, "Tobias Hofmann (tohofman)" <tohof...@cisco.com> wrote:
Hi Flavio,
the only error I saw in 'ovs-vsctl show' was related to the dpdk port. The
other ports all came up fine.
Regarding the "ring error", I'm fine with having it, as long as DPDK is
able to reserve the minimum amount of memory (which, after restarting OvS
process is always the case).
Regards
Tobias
On 05.11.19, 21:07, "Flavio Leitner" <f...@sysclose.org> wrote:
On Tue, 5 Nov 2019 18:47:09 +0000
"Tobias Hofmann \(tohofman\) via discuss" <ovs-discuss@openvswitch.org>
wrote:
> Hi Flavio,
>
> thanks for the insights! Unfortunately, I don't know about the pdump
> and its relation to the ring.
pdump dumps packets from dpdk ports into rings/mempools, so that you
can inspect/use the traffic:
https://doc.dpdk.org/guides/howto/packet_capture_framework.html
But I looked at the dpdk sources now and I don't see it allocating any
memory when the library is initialized, so this is likely a red herring.
> Can you please specify where I can see that the port is not ready
> yet? Is that these three lines:
>
> 2019-11-02T14:14:23.094Z|00070|dpdk|ERR|EAL: Cannot find unplugged
> device (0000:08:0b.2)
The above shows the device is not ready/bound yet.
> 2019-11-02T14:14:23.094Z|00071|netdev_dpdk|WARN|Error attaching
> device '0000:08:0b.2' to DPDK
> 2019-11-02T14:14:23.094Z|00072|netdev|WARN|dpdk-p0: could not set
> configuration (Invalid argument)
>
> As far as I know, the ring allocation failure that you mentioned
> isn't necessarily a bad thing since it just indicates that DPDK
> reduces something internally (I can't remember what exactly it was)
> to support a high MTU with only 1GB of memory.
True for the memory allocated for DPDK ports. However, there is a
minimum which if it's not there, the mempool allocation will fail.
> I'm wondering now if it might help to change the timing of when
> openvswitch is started after a system reboot to prevent this problem
> as it only occurs after reboot. Do you think that this approach might
> fix the problem?
It will help to get the i40e port working, but that "ring error"
will continue as you see after restarting anyways.
I don't know the other interface types, maybe there is another
interface failing which is not in the log. Do you see any error
reported in 'ovs-vsctl show' after the restart?
fbl
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
