• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 230 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.

Sa_chanGetBufferReq and real time issues?

RCReddy
Genius 3575 points

Hi Ti Folks,

                  Thanks for answering my previous posts on SA. I have a question, 

1. shouldn't there be a correction in the Sa_chanGetBufferReq way of implementation. In the example, based on Sa_chanGetBufferReq, say some bytes required are got by malloc. But in real time, since malloc is a costly affair, so some N bytes of memory can be fixed. Can Ti suggest a Value max possible for it [mm.ofcourse, i can trace back the structure and do compute the max value, but probably i can miss some points,, so want to get to get MAX VALUE and CACHE LINE SIZE/aligns requirements] so that real time malloc is avoided.

2. If i recall per Security context MAX allocation is 320 bytes and usage can be anywhere within that 320 bytes. I am expecting a similar MAX SIZE figure for Sa_chanGetBufferReq

Thanks

RC Reddy

  • 0
    TI__Intellectual 2810 points

    Hi, RC:

    The application should call Sa_chanGetBuffReq() to inquere per-channel memory requirements including size and alignment. It is up to the application to allocate the required buffers and pass them back to SA LLD through API Sa_chanCreate(). You may notice that the channel-specific memory requirements only depend on the protocol type and cache line size. Here is the memory size requirement per SA LLD 1.0.5.4:

    IPSEC ESP:   456 (no cache),   512 (cache size = 64)
    IPSEC AH:      456(no cache),    512 (cache size= 64)
    SRTP:              556(no cache)
    Air-Ciphering: 388(no cache)
    Data Mode:     416 (no cache)

    Please note that you will need to consider cache coherence only if you want to share the same channel on multiple cores.

    Yes, it is recommended that the application manage pre-allocated buffers for SA LLD channel memory buffers.

    Best regards,

    Eric

     

     

     

  • 0 in reply to Eric Ruei
    Genius 3575 points

    Hi Eric,

              Thanks a lot for your response/reply. Those vaues helps a lot.

    Thanks

    RC Reddy

  • 0 in reply to RCReddy
    Genius 3575 points

    Hi,

        with this memory requirements

    Air-Ciphering: 388(no cache), 

    Since memory will be accessed by SA, the dedicated cache controller [present in SA] does not involve here with channel and it only involves with security contexts. so i can place this memory in cacheable section as well [say 512 bytes and placement in DDR3 with 128 byte cache alignment] ?? does it looks fine [in the sense, cache invalidation and flush back are taken care in SA LLD API's w.r.t to this memory] ?

    when is this Sa_chanGetShadowHandle called [In this case, the requirement doubles to 1024 bytes with 128 bytes alignment] and in what cases? wanted to know under what cases is this API Sa_chanGetShadowHandle called and how to make use of it.

    Thanks

    RC Reddy

  • 0 in reply to RCReddy
    TI__Intellectual 2810 points

    Hi, RC:

    Yes, the application can allocate 512-byte cache-aligned Security Context buffers from DDR, the SA LLD will invoke OSCL API Osal_saBeginScAccess() and Osal_saEndScAccess(), which are implemented by application for memory-specific cache operation.

    Shadow instance is created to resolve an unique customer use case. Please refer to appendix2 "Shadow Instance for mixed-Endian operation" for details. It is not applicable for DSP-only devices. You should disable this featute by clearing control bit sa_SIZE_CONFIG_CREATE_SHADOW_INST at Sa_ChanSizeCfg_t and Sa_SizeCfg_t.

    Best regards,

    Eric