Skip to content

Suggestion: reading/changing value of ARP_TABLE_SIZE to improve performance #1

@richardloxley

Description

@richardloxley

Thanks for this example code!

Not an issue as such, but it's possible to improve performance by using ARP_TABLE_SIZE instead of 5 when batching up the requests, e.g.:

        while(target_ip.addr != last_ip.addr){
            esp_ip4_addr_t currAddrs[ARP_TABLE_SIZE]; // save current loop ip
            int currCount = 0; // for checking Arp table use

            // send ARP_TABLE_SIZE ARP request at a time because ARP table has limit size
            for(int i=0; i<ARP_TABLE_SIZE; i++){
                nextIP(&target_ip); // next ip
                if(target_ip.addr != last_ip.addr){
                    esp_ip4addr_ntoa(&target_ip, char_target_ip, IP4ADDR_STRLEN_MAX);
                    currAddrs[i] = target_ip;
                    ESP_LOGI(TAG, "Success sending ARP to %s", char_target_ip);

                    etharp_request(netif, &target_ip);
                    currCount++;
                }
                else break; // ip is last ip in subnet then break
            }

The default value for ARP_TABLE_SIZE is 10, which means the requests take half the time compared to sending them in batches of 5.

Or it's possible to increase ARP_TABLE_SIZE to improve performance further. I've set it to 255 so I can scan a whole subnet in one go. (This will be at the expense of memory consumed for the table in etharp.c - increasing it from 10 to 255 will increase memory usage from 240 bytes to 6120 bytes - so it depends if the trade-off is acceptable for your use case.)

To override the definition of ARP_TABLE_SIZE I added the following line to my top-level CMakeLists.txt:

add_compile_definitions(ARP_TABLE_SIZE=255)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions