Evgeny -

It's on the list of patches to be applied for the next round.

donald

On Wed, Feb 3, 2016 at 7:16 AM, Evgeny Uskov <[email protected]> wrote:

> Hi,
>
> Any news regarding the patching process?
>
> --
> | Evgeny Uskov  | HLL l QRATOR
> | mob.: +7 916 319 33 20
> | skype: evgeny_uskov
> | mailto: [email protected]
> | visit: www.qrator.net
>
> On Mon, Jan 25, 2016 at 5:55 PM, Evgeny Uskov <[email protected]> wrote:
>
>> Paul,
>>
>> Please see the attached files created with "git format-patch".
>>
>> Regarding the chunk with bgp_dump_obuf creation, it was done
>> intentionally with the following purpose.
>> The key idea of the patch is that if the portion of data (i.e. the RIB
>> entry corresponding to the prefix) is greater than the remaining space in
>> the current MRT record, then we finalize the current record and put this
>> portion of data to the next record. The function writing the portion of
>> data (bgp_dump_routes_attr) does not perform size checking, and hence we
>> decided to implement the logic above in the following way.
>> 1) We increased the max size of bgp_dump_obuf;
>> 2) after each portion of data we compare the current data size
>> with BGP_MAX_PACKET_SIZE + BGP_DUMP_MSG_HEADER + BGP_DUMP_HEADER_SIZE. If
>> the data size is greater than this value, then we finalize the record with
>> all the RIB entries except this last one (which does not fit to max packet
>> size), and the last RIB entry goes to the next data portion.
>>
>> The size of bgp_dump_obuf in this case should be at least
>> BGP_MAX_PACKET_SIZE + BGP_DUMP_MSG_HEADER + BGP_DUMP_HEADER_SIZE + (max
>> size of the RIB entry). In the patches attached to this letter we removed
>> the magic constant 0x4000, set the size in the following way:
>>
>> -  bgp_dump_obuf = stream_new (BGP_MAX_PACKET_SIZE + BGP_DUMP_MSG_HEADER
>> -                              + BGP_DUMP_HEADER_SIZE);
>> +  bgp_dump_obuf = stream_new ((BGP_MAX_PACKET_SIZE << 1)
>> +                              + BGP_DUMP_MSG_HEADER +
>> BGP_DUMP_HEADER_SIZE);
>>
>> I.e. we added one extra BGP_MAX_PACKET_SIZE which should be enough to
>> contain any possible RIB entry.
>>
>> --
>> | Evgeny Uskov  | HLL l QRATOR
>> | mob.: +7 916 319 33 20
>> | skype: evgeny_uskov
>> | mailto: [email protected]
>> | visit: www.qrator.net
>>
>> On Mon, Jan 25, 2016 at 4:16 PM, Paul Jakma <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> On Mon, 25 Jan 2016, Evgeny Uskov wrote:
>>>
>>> The easiest way to eliminate the problem is to create multiple MRT
>>>> records
>>>> if there is too much data for a prefix. Please see the attached file
>>>> dump_fix.patch implementing such solution.
>>>>
>>>>
>>>> Finally, we have noticed a typo in the description of "dump bgp"
>>>> command.
>>>> Please see the attached file comment_fix.patch.
>>>>
>>>
>>> Nice. Thanks!
>>>
>>> One thing, could you supply it as a git commit, or otherwise just supply
>>> a commit message.
>>>
>>> Also, did you intend to submit this chunk? If yes, what's the purpose?
>>>
>>> -  bgp_dump_obuf = stream_new (BGP_MAX_PACKET_SIZE + BGP_DUMP_MSG_HEADER
>>> -                              + BGP_DUMP_HEADER_SIZE);
>>> +  bgp_dump_obuf = stream_new (0x4000);
>>>
>>> regards,
>>> --
>>> Paul Jakma      [email protected]  @pjakma Key ID: 64A2FF6A
>>> Fortune:
>>> Our country has plenty of good five-cent cigars, but the trouble is
>>> they charge fifteen cents for them.
>>>
>>
>>
>
> _______________________________________________
> Quagga-dev mailing list
> [email protected]
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev

Reply via email to