• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 568 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMDSIDK574: GMAC_SW interrupt pacing

Christian Leeb
Expert 1690 points

Part Number: TMDSIDK574

Hi TI,

refrerring to TRM AM5748, section 24.12.4.5.5 Interrupt Pacing:

 



For a test, I set rx_pacing to 500us: ethtool -C eth0 rx-usecs 500.

I'm using Linux SDK5.3. Driver sets INT_PRESCALE and WR_C0_RX_IMAX as expected:

WR_INT_CONTROL Read at address  0x4848520C : 0x003F01F4

--> pacing is enabled

--> INT_PRESCALE = 1F4h = 500d, 500 x GMAC_MAIN_CLK^-1 (125MHz) = 4us

WR_C0_RX_IMAX: Read at address  0x48485270 (0xb6f92270): 0x00000002 --> 2 interrupts per 1ms, as expected. This is intr_max

"The interrupt pacing module counts the number of interrupts that occur over a 1 ms interval of time.". Let's assume I get 10 rx ints per ms

-> intr_cnt = 10

If we look a the algorithm

if (intr_count > 2*intr_max)

pace_timer = 255;

else ...

Or

if (10 > 4)

pace_timer = 255;

else ...

The way I understand the algo is: 

- interrupts are (always) suppressed for 255*4 = about 1ms

- always the first "if" is taken, so we get and interrputs every second

In reality I get an int every 500us.

So it seems I do not fully understand the algorithm or is it not properly documented?

Best regards, Chris

  • 0
    TI__Mastermind 40080 points

    Hi,

    Which Linux SDK are you using? Are you using the default kernel configuration? How are you measuring the pacing time? Is your application needing a specific pacing time?

    The default SDK from TI uses NAPI scheduling which is essentially polling. While the driver supports interrupt pacing it's affect is muted somewhat since NAPI schedules does not directly use RX interrupts for packet processing. 

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Expert 1690 points

    Hi Schuyler

    In this questions I'm referring to "pure" hardware HMAC_SW interrupt pacing, as described in the AM5748 TRM, not to NAPI. We have a different question open for NAPI behaviour. I'm aware that NAPI does additional rx pacing, rsp. polling.

    I'm using SDK5.3 as mentioned in my question. Default Kernel config. I'm not measuring anything. I'm just trying to understand the algo, which doesn't make sense IMHO or I did not understand the description.

    Regards, Chris

  • 0 in reply to Christian Leeb
    TI__Mastermind 40080 points

    Hi,

    I am currently out of the office until the 4th. I will review the example you provided with the IP team and also discuss with the driver developer. 

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    TI__Mastermind 40080 points

    Hi,

    I am still working on this question as well as the other question on pacing. While this question is more about the algorithm it is closely related to the other question being asked concerning interrupt pacing and controlling it and trying to make the processing more deterministic. This is the other thread: 

    Link to additional question on interrupt pacing.

    For the moment what I learned with the other post is that Linux is being used the interrupt pacing is not completely independent of NAPI due to the implementation of the CPSW driver.

    I do see your question about how the algorithm works though, since based on the example you provided it looks to be to be generating the interrupts based on mS instead of the 500uS range specified in the ethtool command. 

    Best Regards,

    Schuyler