Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
The advantage of this feature, if an ingress queue is about to overflow, SPD tries to first drop "less important" packets.
It's unusual to see ingress queues fill, so before worrying about SPD, you might try to determine why the ingress queue is filling.
Also, for some transient ingress queue bursts, an alternative is to just increase the queue size so the queued packets aren't as likely to be dropped. (Often default ingress queues sizes are relatively "shallow" because it's unusual, again, for this queue to fill.)
PS:
BTW, for BGP, are the peers taking advantage of full sized packets? (I.e. what's the MTU being used by BGP?)
PPS:
Large BGP updates, like the initial load of the Internet's routes, will often queue up in ingress queues, as the control plane tries to process them. Larger, and fewer, BGP packets, slightly decrease the packet processing load for these.
