em. igb performance test

[Nomad Esst]

Thank you allWe'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"
>
>