em. igb performance test

[Nomad Esst]

Thank you Adrian. Do you have any ideas on how to add a buffer until the link is up?
Regards. 


     On Sunday, September 6, 2015 7:08 PM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
   
 

 No, I meant you'd likely have to do that in order to get the
functionality you desire!


-a


On 6 September 2015 at 01:40, Nomad Esst <noname.esst at yahoo.com> wrote:
> Thank you all
> We've recently found out that if we change the media type to 10BaseT all ten
> packets are arrived. And if we change the number of packets to 2 in
> tcpreplay like
>
> tcpreplay -i gbeth0 -l 2 ospf_hello.pcap
>
> at least 1 packet is arrived at the time (while the media type is 10BaseT
> and auto negotiation is disabled). but sometimes the second packet is
> missed.
>
> Adrian, you said that someone is working on adding a buffer to queue the
> packets until the interface come up. How can I contact with him/her?
>
> Regards.
>
>
>
> On Sunday, September 6, 2015 1:00 PM, Adrian Chadd <adrian.chadd at gmail.com>
> wrote:
>
>
>
> Hi,
>
> I can imagine someone hacking up driver support for buffering up to
> 'n' packets until the link comes up, or timing them out if the link
> doesn't come up in time. Thing is, bringing an interface up doesn't
> guarantee it'll be up and live by the time the next command is run.
> The cleanest way to get some clean behaviour here is to wait until the
> link shows active before running the next command.
>
> hth,
>
>
> -adrian
>
>
> On 5 September 2015 at 22:24, Nomad Esst <noname.esst at yahoo.com> wrote:
>> Thanks for your reply. How can I solve this problem? e.g. speed up the
>> link
>> negotiation, buffer the packets while link negotiation is being done ? Any
>> ideas?
>>
>> Regards.
>>
>>
>>
>> On Saturday, September 5, 2015 8:01 PM, Adrian Chadd
>> <adrian.chadd at gmail.com> wrote:
>>
>>
>>
>> Hi,
>>
>> It's likely a combination of STP and how long it takes to do link
>> negotiation. Packets transmitted during link negotiation will be lost.
>>
>>
>>
>> -adrian
>>
>>
>> On 5 September 2015 at 08:03, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
>>> On Sat, Sep 05, 2015 at 02:45:28PM +0000, Nomad Esst via freebsd-hackers
>>> wrote:
>>>
>>>> Hi allDuring some performance tests, we found out some weird problems.
>>>> We
>>>> use a shell script that do the following :
>>>> do from 1 to 10Shutdown em/igb interfacesleep 3Bring em/igb interface
>>>> uptcpreplay -i em0 -l ospf_hello.pcap sleep3end
>>>> By running this shell on one side we expect 10 ospf hello packets to get
>>>> arrived at the other side, but tcpdump (on the other side) shows 4,
>>>> sometimes 8 and etc ... (not all 10 packets are arrived at the other
>>>> side).We test this scenario with a Cisco router, and all packets are
>>>> received at the Cisco side. What causes this packet loss in FreeBSD
>>>> (maybe
>>>> in em or igb drivers)?I know that this scenario may not have any use in
>>>> the
>>>> real world, but I'm curious, why Cisco don't have such behavior.Thanks
>>>> in
>>>> advance.
>>>
>>> uping interface not momentaly.
>>> packets sending to down interface will be lost.
>>> try to wait `status: active` before run tcpreplay.
>>> Also, check STP off on interconnect switch you port.
>>> _______________________________________________
>>> freebsd-hackers at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to
>>> "freebsd-hackers-unsubscribe at freebsd.org"
>>
>>
>
>