Code Monkey home page Code Monkey logo

Comments (7)

seladb avatar seladb commented on June 11, 2024

I think it's possible to support a configurable packet size and have a default of RTE_MBUF_DEFAULT_BUF_SIZE.

Please note we probably also need to change this:

const int MBufRawPacket::MBUF_DATA_SIZE = MBUF_DATA_SIZE_DEFINE;

Would you consider opening a PR with this change?

from pcapplusplus.

gyl30 avatar gyl30 commented on June 11, 2024

#ifndef MBUF_DATA_SIZE_DEFINE
# define MBUF_DATA_SIZE_DEFINE RTE_MBUF_DEFAULT_DATAROOM
#endif

const int MBufRawPacket::MBUF_DATA_SIZE = MBUF_DATA_SIZE_DEFINE;

memPool = rte_pktmbuf_pool_create(mempoolName, mBufPoolSize, MEMPOOL_CACHE_SIZE, 0, RTE_MBUF_DEFAULT_BUF_SIZE, rte_socket_id());

result = rte_pktmbuf_pool_create(
mempoolName,
mempoolSize,
MEMPOOL_CACHE_SIZE,
0,
RTE_MBUF_DEFAULT_BUF_SIZE,
rte_socket_id()
);
if (result == NULL)

As seen here, both MBUF_DATA_SIZE_DEFINE and rte_pktmbuf_pool_create depend on RTE_MBUF_DEFAULT_DATAROOM. Do we modify the values in MBUF_DATA_SIZE_DEFINE and rte_pktmbuf_pool_create when enabling Jumbo Frame using macros? For example, like this.

MBufRawPacket.cpp

#ifndef MBUF_DATA_SIZE_DEFINE                                                                                                                                                        
#ifdef JUMBO_FRAME_SIZE_DEFINE                                                                                                                                                       
#   define MBUF_DATA_SIZE_DEFINE (JUMBO_FRAME_SIZE_DEFINE + RTE_PKTMBUF_HEADROOM)                                                                                                    
#else                                                                                                                                                                                
#   define MBUF_DATA_SIZE_DEFINE RTE_MBUF_DEFAULT_DATAROOM                                                                                                                           
#endif                                                                                                                                                                               
#endi

const int MBufRawPacket::MBUF_DATA_SIZE = MBUF_DATA_SIZE_DEFINE;

DpdkDevice.cpp and KniDevice.cpp

#ifdef JUMBO_FRAME_SIZE_DEFINE
#   define MBUF_DATA_SIZE_DEFINE (JUMBO_FRAME_SIZE_DEFINE + RTE_PKTMBUF_HEADROOM)
#else
#   define MBUF_DATA_SIZE_DEFINE RTE_MBUF_DEFAULT_DATAROOM
#endif
    // create mbuf pool                                                                                                                                                              
    memPool = rte_pktmbuf_pool_create(mempoolName, mBufPoolSize, MEMPOOL_CACHE_SIZE, 0, MBUF_DATA_SIZE_DEFINE, rte_socket_id());  

Such modifications appear quite messy. Perhaps we could redefine MBUF_DATA_SIZE_DEFINE in one place and then use it directly in other places.

from pcapplusplus.

tigercosmos avatar tigercosmos commented on June 11, 2024

If only three places, it should be fine. Personally, I consider it is more appropriate to define the value within the header, yet I'm struggling to identify the suitable header for this purpose.

from pcapplusplus.

gyl30 avatar gyl30 commented on June 11, 2024

If only three places, it should be fine. Personally, I consider it is more appropriate to define the value within the header, yet I'm struggling to identify the suitable header for this purpose.

The beginning of a bad smell indeed. Yes, we should define it in a header file.

from pcapplusplus.

seladb avatar seladb commented on June 11, 2024

I think that instead of a const value, we can add it to the DpdkDevice constructor as an optional argument (with a default size of RTE_MBUF_DEFAULT_BUF_SIZE) so users can set whatever value they want.

MBufRawPacket::init() takes a DpdkDevice as an argument so we can extract this value from there.

Regarding KniDevice - I wouldn't change anything unless you really need it. KNI has been deprecated in DPDK and we'll soon remove it from PcapPlusPlus code-base

from pcapplusplus.

gyl30 avatar gyl30 commented on June 11, 2024

I've noticed that we try to minimize the inclusion of DPDK headers in our header files. If we modify the function signature in the header file to add a default value for the function parameter, RTE_MBUF_DEFAULT_BUF_SIZE, it will inevitably require including DPDK headers. I'm not sure if this is the right approach.

from pcapplusplus.

seladb avatar seladb commented on June 11, 2024

I've noticed that we try to minimize the inclusion of DPDK headers in our header files. If we modify the function signature in the header file to add a default value for the function parameter, RTE_MBUF_DEFAULT_BUF_SIZE, it will inevitably require including DPDK headers. I'm not sure if this is the right approach.

Yes, you're right. Maybe the default value can be some magic number (like -1 or something else) which will translate to RTE_MBUF_DEFAULT_BUF_SIZE. We can mention it in the doxygen documentation

from pcapplusplus.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.