>On 07/17/2017 08:00 AM, John Ferlan wrote:
>>
> On 07/16/2017 05:04 PM, Laine Stump wrote:
>> On 07/11/2017 09:01 PM, ZhiPeng Lu wrote:
>>> This patchs allow to set the buffer size for netlink socket in
>>> the libvirtd configuration file. The default buffer size remain
>>> as before at 128k.
>> See my more detailed response to your earlier patch here:
>>
>>
>> https://www.redhat.com/archives/libvir-list/2017-July/msg00566.html
>>
>> There should be no need to configure the initial libnl buffer size,
>> because we enable MSG_PEEK on the libnl sockets (and recent versions of
>> libnl have it turned on by default anyway). If that's not permitting the
>> buffer to auto-grow as necessary, then there is a different bug somewhere.
>>
>> If an old version of libnl is the problem, then perhaps a patch which
>> just adds a comment in virNetlinkCreateSocket to "summarize" what gets
>> discovered w/r/t MSG_PEEK and the "correct" minimum version of libnl so
> that the "next" person to come this way will have a chance at
>> understanding what needs to be done without going through the submit a
>> patch changing the size again!
>>
> >All that said, having it be configurable could be useful for someone who
> >has a system that doesn't have that version, while still working as
> >expected for the right version.
>I think it may need to be a fairly unusual combination of kernel,
>libvirt, and libnl versions, combined with pretty "big" hardware in
>order for that to happen. More information from ZhiPeng about the
>versions of those packages might allow us to make a better informed
>decision.
>Workarounds are okay when necessary. But adding a config parameter is
>something that would need to be left in forever, leaving more code to
>maintain, and all for a bug that shouldn't even be there today, much
>less 6 months or a year from now - turning on message peek was supposed
>to "eliminate this problem totally and permanently". If it didn't, I'd
>like to know why.
>ZhipPeng - can you tell us more about your setup? package versions,
>hardware, example XML, gdb backtrace at the instant the error message is
>logged?
----- Thanks.
i will try to update libnl3 to 3.2.29 ,now libnl3 is 3.2.8 in my host
芦志朋 luzhipeng
IT开发工程师 IT Development
Engineer
操作系统产品部/中心研究院/系统产品 OS Product Dept./Central R＆D Institute/System Product
 |  深圳市南山区科技南路55号中兴通讯研发大楼33楼 33/F, R&D Building, ZTE Corporation Hi-tech Road South, Hi-tech Industrial Park Nanshan District, Shenzhen, P.R.China, 518057 T: +86 755 xxxxxxxx F:+86 755 xxxxxxxx M: +86 xxxxxxxxxxx E: lu.zhipeng@xxxxxxxxxx www.zte.com.cn |
>
> On 07/16/2017 05:04 PM, Laine Stump wrote:
>> On 07/11/2017 09:01 PM, ZhiPeng Lu wrote:
>>> This patchs allow to set the buffer size for netlink socket in
>>> the libvirtd configuration file. The default buffer size remain
>>> as before at 128k.
>> See my more detailed response to your earlier patch here:
>>
>>
>> https://www.redhat.com/archives/libvir-list/2017-July/msg00566.html
>>
>> There should be no need to configure the initial libnl buffer size,
>> because we enable MSG_PEEK on the libnl sockets (and recent versions of
>> libnl have it turned on by default anyway). If that's not permitting the
>> buffer to auto-grow as necessary, then there is a different bug somewhere.
>>
> If an old version of libnl is the problem, then perhaps a patch which
> just adds a comment in virNetlinkCreateSocket to "summarize" what gets
> discovered w/r/t MSG_PEEK and the "correct" minimum version of libnl so
> that the "next" person to come this way will have a chance at
> understanding what needs to be done without going through the submit a
> patch changing the size again!
>
> All that said, having it be configurable could be useful for someone who
> has a system that doesn't have that version, while still working as
> expected for the right version.
I think it may need to be a fairly unusual combination of kernel,
libvirt, and libnl versions, combined with pretty "big" hardware in
order for that to happen. More information from ZhiPeng about the
versions of those packages might allow us to make a better informed
decision.
Workarounds are okay when necessary. But adding a config parameter is
something that would need to be left in forever, leaving more code to
maintain, and all for a bug that shouldn't even be there today, much
less 6 months or a year from now - turning on message peek was supposed
to "eliminate this problem totally and permanently". If it didn't, I'd
like to know why.
ZhipPeng - can you tell us more about your setup? package versions,
hardware, example XML, gdb backtrace at the instant the error message is
logged?
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
