[External] Add UDP transport for rsyslog

[Gleb Semenov]

Hi Jian!

Thank You for this note. We must pay attention to this circumstance 
during test phase.

Regards!

Gleb

On 19.01.2023 08:25, Zhang Jian wrote:
> Hi Gleb,
>
> I share a problem I encountered some time ago about using `UDP`
> rsyslog.If there are more UDP(About 50 logs per second) logs, will
> block ipmi messages,
> due to bad udp tx performance.
>
> My network is a 1000M direct connection, using `iperf3` to verify.
> ```
> ./iperf3 -u -c 192.168.1.2 -b 1000m -t 10 -p 1314
> Connecting to host 192.168.1.2, port 1314
> [  5] local 192.168.1.108 port 55038 connected to 192.168.1.2 port 1314
> [ ID] Interval           Transfer     Bitrate         Total Datagrams
> [  5]   0.00-1.00   sec  58.0 KBytes   475 Kbits/sec  41
> [  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec  0
> [  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec  0
> [  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec  0
> [  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec  0
> [  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec  0
> [  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec  0
> [  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec  0
> [  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec  0
> [  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec  0
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Jitter
> Lost/Total Datagrams
> [  5]   0.00-10.00  sec  58.0 KBytes  47.5 Kbits/sec  0.000 ms  0/41
> (0%)  sender
> [  5]   0.00-11.69  sec  58.0 KBytes  40.6 Kbits/sec  0.030 ms  0/41
> (0%)  receiver
> ```
>
> I found a patch[0] that may fix it.
> Apply this patch:
> ```
> iperf3 -u -c 192.168.1.2 -b 1000m -t 10 -p 1314
> Connecting to host 192.168.1.2, port 1314
> [  5] local 192.168.1.108 port 34362 connected to 192.168.1.2 port 1314
> [ ID] Interval           Transfer     Bitrate         Total Datagrams
> [  5]   0.00-1.01   sec  23.2 MBytes   193 Mbits/sec  16782
> [  5]   1.01-2.01   sec  24.8 MBytes   209 Mbits/sec  17977
> [  5]   2.01-3.00   sec  31.5 MBytes   266 Mbits/sec  22819
> [  5]   3.00-4.00   sec  28.3 MBytes   237 Mbits/sec  20461
> [  5]   4.00-5.00   sec  27.6 MBytes   232 Mbits/sec  19996
> [  5]   5.00-6.00   sec  28.3 MBytes   237 Mbits/sec  20498
> [  5]   6.00-7.00   sec  30.1 MBytes   252 Mbits/sec  21796
> [  5]   7.00-8.00   sec  28.5 MBytes   239 Mbits/sec  20609
> [  5]   8.00-9.00   sec  25.0 MBytes   210 Mbits/sec  18140
> [  5]   9.00-10.00  sec  24.1 MBytes   202 Mbits/sec  17457
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Jitter
> Lost/Total Datagrams
> [  5]   0.00-10.00  sec   271 MBytes   228 Mbits/sec  0.000 ms
> 0/196535 (0%)  sender
> [  5]   0.00-10.04  sec   271 MBytes   227 Mbits/sec  0.065 ms
> 0/196535 (0%)  receiver
> ```
>
> [0]:https://github.com/AspeedTech-BMC/linux/commit/05c055107d56cd699bc88a3440665d95d9a634ff
>
> Cheers,
> Jian
>
>
> On Wed, Jan 18, 2023 at 7:46 PM Gleb Semenov<g.semenov at yadro.com>  wrote:
>> Hello colleagues!
>>
>> I'm a new member of the Yadro OBMC team and currently working on modifications of the phosphor logging service. Our client requested us to make OBMC's rsyslog to use UDP transport for remote logging. Currently it uses just TCP and this configuration is hard-coded.
>>
>> It looks like the phosphor-rsyslog-config has only one external dependency, namely the sdbusplus library, which provides appropriate DBUS interface handler to configure network parameters. Also it needs to modify DBUS interface description for network client.
>>
>> The following should be performed:
>>
>> Modification of the xyz/openbmc_project/Network/Client.interface.yaml interface to add the protocol attribute.
>> Handling for the  interface changes in the code of the dbusplus library.
>> Corresponding changes to the phosphor-rsyslog-config service.
>> Proper changes to the REST/redfish API.
>> Modification of the web interface and command line tools.
>>
>> Also, current DBUS interface to the object implies two independent messages to change network parameters, one to set the IP-address, and the other to set the port number. They are not atomic and configuring just one parameter yields in undesirable state transitions of the service to configure. It is good to send all the parameters in one "atomic" message. But, I'm understand that this may require to persist current network parameters on both sides of transmission (or, at least, to have all of them on sending side upfront).
>>
>> So, it needs to add  DBUS getters/setters for just protocol type, and all parameters at once.
>>
>> I'm interested in what other components may be affected by such improvements?
>>
>> Your comments will be appreciated.
>>
>> Regards!
>>
>> Gleb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230119/be81d7cd/attachment.htm>