TRex STF >65K pkts support

[rashikrishna]

Hi,

TRex currently doesn't support, flow with >65K packets. I saw it is hard coded here:

void SetPktNum(uint32_t pkt_id){
        assert(pkt_id<65000);
        m_dir_pkt_num=(uint16_t)pkt_id;
    }

https://github.com/cisco-system-traffic-generator/trex-core/blob/master/src/bp_sim.h#L1529

I have flow with more number of packets, so I have just increased this value in the code and after increasing the mbuf memory allocated, I could run the traffic just fine.

Any reason for this specific value??

Can I add support to make it configurable in the trex_cfg.yaml file?

[hhaim]

@rashikrishna you are using a legacy STF mode, Any reason why you don't use ASTF which does not have this limitation ?

[rashikrishna]

Hi @hhaim

We want to replay packets with almost identical timing. In ASTF we don't have that control since it depends on the TCP stack. Hence we are using STF mode.

Is there a specific reason for limiting the number of packets?? If not we can add support to specify the number of packets in the trex_cfg.yaml file.

[hhaim]

@rashikrishna Why do you care about timing with TCP? STF is a problematic model for testing as it does not handle this case of drop of packet for example and the timing is critical and could create out of order to the device in high load.

thanks Hanoh

[rashikrishna]

Yes @hhaim, we are aware of the drawbacks of using STF mode. But for now we have the entire setup build on STF mode. It will be far more convenient for us to add the support in STF mode than to switch to ASTF mode.

In future, we will definitely scope to switch to ASTF. But for now we need to add this in STF mode.

[rashikrishna]

What do you recommend @hhaim should we add it in our own private trex build or add to the public repo as well?

Also, is there a reason for setting 65k ?

Thanks a lot!

[rashikrishna]

@hhaim any update on this? If it is not relevant..you can close this.