SvenRoederer
commented
3 years ago had it running for some days on a NanoStation-AC (64MB RAM) and a TPlink EAP225-Outdoor (128MB RAM). Both devices are configured as STA to the same AP.
64MB devices (NanoStation AC)
Monitoring shows for the unpatched NS-AC average uptime of only some hours, with a lot of traffic loss as of crashed olsrd.
Same setup with the patched "smallbuffer" driver on the NS-AC - runnig for 4days without reboot or crash of olsrd. 
128MB devices (TPLink EAP225 Outdoor v1)
There are no indication in the monitoring, that any performance-parameter has changed.
Summary
As we use the non-ct driver only for 802.11s / STA, which usually have a low client-count, I don't expect any performance problems with smaller buffers on 128MB or 64MB devices. For AP-use it might be different, but was not tested. But using this patch allows reliable use of 64MB devices, whereas will for sure not make AP-situations reboot randomly. So let's follow @FreifunkFranken and @weimarnetz
adschm
For some ath10-wave1 boads we use the non-ct driver (#696). Test have shown that some boards are not running stable with this. I can confirm for a ubnt_nanostation_ac. This seems to be caused by the "low RAM" these boards have (NanoStation AC has 64MB). That is the same reason OpenWrt made an official "ath10-ct-smallbuffers" package.
This imports the patch that was used on OpenWrt, before they switched to the "ct-"driver, to address the RAM-issue.
As the "Wave1" issue only affects some boards it seems not worth to create a "ath10-smallbuffers" package. So let's use the smallbuffers for all boards, even they have 128 MB (as EAP225-outdoor which is not affected by sudden reboots).