After running a bisect between tags libnl3_2_21 and libnl3_2_22 I identified
the fixer commit to be 807fddc nl: Increase receive buffer size to 4 pages
commit 807fddc4cd9ecb12ba64e1b7fa26d86b6c2f19b0
Author: Thomas Graf <email address hidden>
Date: Wed May 8 13:52:27 2013 +0200
nl: Increase receive buffer size to 4 pages
Assuming that the kernel does not send more than a page is no longer valid,
and enabling MSG_PEEK'ing by default to figure out the exact message buffer
requirements can have a negative influence on the performance of existing
applications. Bumping the default receive buffer space to 4 pages seems
a sane default.
Signed-off-by: Thomas Graf <email address hidden>
---
After applying this patch on top of the current trusty-updates this problem
is not longer exhibited and I can attach the full 128 VFs to the guest.
I am proposing this patch for SRU, and I already updated the description
with the reproduction steps.
Hello,
After running a bisect between tags libnl3_2_21 and libnl3_2_22 I identified
the fixer commit to be 807fddc nl: Increase receive buffer size to 4 pages
commit 807fddc4cd9ecb1 2ba64e1b7fa26d8 6b6c2f19b0
Author: Thomas Graf <email address hidden>
Date: Wed May 8 13:52:27 2013 +0200
nl: Increase receive buffer size to 4 pages
Assuming that the kernel does not send more than a page is no longer valid,
and enabling MSG_PEEK'ing by default to figure out the exact message buffer
requirements can have a negative influence on the performance of existing
applications. Bumping the default receive buffer space to 4 pages seems
a sane default.
Signed-off-by: Thomas Graf <email address hidden>
---
After applying this patch on top of the current trusty-updates this problem
is not longer exhibited and I can attach the full 128 VFs to the guest.
I am proposing this patch for SRU, and I already updated the description
with the reproduction steps.