I believe I need to first start with stating that not all Scalable Platforms are the same. When reviewing documentation and KB Solutions, care needs to be taken to determine if the information is specific for ElasticXL, Maestro, or Scalable Chassis. This is not always apparent at first glance, so be extra careful when applying information to Scalable Platforms. Specifically, within the Scalable Platform Admin guide, there is a section about how to make changes to BPEthX. This is within the Scalable Chassis section of the guide, and can only be applied to Scalable Chassis.
Something to note: on Maestro, BPEthX is a pseudo interface, whereas on a Scalable Chassis, BPEthX is a physical interface. This causes confusion in situations as described here.
The pseudo interfaces BPEthX within Maestro specifically represent the aggregation of multiple physical backplane interfaces. The actual packet processing and buffering happen on the physical interfaces—not on the pseudo interface itself. Pseudo interfaces like BPEth0 do not have their own hardware buffers. Even though you see the setting from clish, it does nothing to affect the traffic across the physical interfaces.
As you found out, using the ethtool -g or -G options provide errors when run against pseudo interfaces like BPEth0. This is supposed to prevent conflicts that could arise from trying to set or display buffer sizes on a logical interface that does not directly interact with hardware queues. Therefore, the changes need to be done on the underlying physical interfaces ethsBP* that are associated with the pseudo interface.
To change the buffer size for the underlying physical interfaces, the dbset command is the way to set it, along with the dbset :save command to save the changes for future boots - like the save config within clish. To see the setting, the ethtool -g command can be used on the physical interface, or the dbget command. Note: the dbget command will only show anything if it has previously been set manually.
These changes should be made in incremental changes, not immediately going to the largest value allowed. The ringsize can affect other things on the system, such as:
- Increased Memory Usage - be sure to monitor before and after making any changes
- Higher latency - packets can spend more time in the buffer before being processed.
- Diminished returns - depends on where the bottleneck is (CPU, driver, hardware, etc.)
- Modifying buffer sizes can cause interface resets or require a reboot, potentially impacting traffic.
- Always perform during a maintenance window, and make sure you have console access in case the system becomes unresponsive
- Make sure you know the maximum supported buffer size and never exceed them when setting the value, otherwise there may be errors or unexpected behaviors.
To answer your specific questions:
- You are reviewing the information for the pseudo interface, not the physical interface. This interface does not have it's own hardware buffers and can be ignored. If you look back at the information you presented, you will see the physical interfaces default with a setting of 1024, not 256. This shows even in a default state the settings do not affect each other.
- Yes, this would be the expectation. If the setting has been modified from the default, you would also be able to see it with a dbget command.
- Based on your experience, and what I have found, the "dbset :save" command is how to ensure the setting is saved. The rc.local file should not need to be changed.
- Not sure, and I don't want to speculate here. The best way to get an answer would probably be from TAC.
- Best practices are to only make changes where they are needed - don't make blanket changes unless it is specifically documented. sk183094 is only providing the commands for how to make the changes. It is not meant to be inferred that changing one automatically means the other should be changed. Make the change to the rx buffer and monitor.
- Not knowing your full topology and configuration I'm not sure. Making an assumption there are 2 MHOs, and 2 members within the Security Group, there would be 1 downlink from each MHO per member (2 links) * 2 member = 4 physical links making up the backplane.
- Specifically for the rx and tx ringsize - yes.
- This may be possible. Knowing how the different Scalable Platforms are different from each other is paramount for reading the solutions. If you know these, the information takes on a different light. We can take this back to the documentation team and see what can be done.
Hope this helps...
