You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tagging @gdamore, as he emailed me, and I'm long overdue putting it in the public record. The following text is his:
. . .
On allocb() using a less persistent attempt (and esballoc() and desballoc()):
I’m in favor of adding this as an option for NIC drivers. Most ethernet drivers can gracefully deal with packet loss, and this is indeed preferable to trying extra hard to allocate a packet. So for ethernet (and WIFI) drivers in particular, KM_NORMALPRI is preferable. (Note that this won’t apply to all NIC drivers. Note also that esballoc and desballoc are probably exclusively, or nearly so, used by NIC drivers trying to minimize DMA losses.)
Other places are less forgiving.
Our console, HID (keyboards, mice, etc.) and USB stacks use mblks. These are less likely to be forgiving of allocation failure. They shouldn’t be impacted.
IP is forgiving. But, at the same time if we’ve already paid the cost to obtain the packet from the hardware (which is likely not to be trivial), we probably don’t want to be too aggressive in dropping the packet. I’d vote for not using KM_NORMALPRI for things in the middle portion of the stack as a result.
For the same reasons in # 2, I would not use KM_NORMALPRI in msgpullup/pullupmsg.
So, to recap, I’d have it be opt-in, and only done in the receive routines for device drivers that can easily cope with it.
(Hmm… it might be a good idea to do this for allocb()’s that are used when looping back mblks sent downstream for promiscuous devices… I can see arguments both way in that case.)
. . .
The text was updated successfully, but these errors were encountered:
Tagging @gdamore, as he emailed me, and I'm long overdue putting it in the public record. The following text is his:
. . .
On allocb() using a less persistent attempt (and esballoc() and desballoc()):
I’m in favor of adding this as an option for NIC drivers. Most ethernet drivers can gracefully deal with packet loss, and this is indeed preferable to trying extra hard to allocate a packet. So for ethernet (and WIFI) drivers in particular, KM_NORMALPRI is preferable. (Note that this won’t apply to all NIC drivers. Note also that esballoc and desballoc are probably exclusively, or nearly so, used by NIC drivers trying to minimize DMA losses.)
Other places are less forgiving.
Our console, HID (keyboards, mice, etc.) and USB stacks use mblks. These are less likely to be forgiving of allocation failure. They shouldn’t be impacted.
IP is forgiving. But, at the same time if we’ve already paid the cost to obtain the packet from the hardware (which is likely not to be trivial), we probably don’t want to be too aggressive in dropping the packet. I’d vote for not using KM_NORMALPRI for things in the middle portion of the stack as a result.
For the same reasons in # 2, I would not use KM_NORMALPRI in msgpullup/pullupmsg.
So, to recap, I’d have it be opt-in, and only done in the receive routines for device drivers that can easily cope with it.
(Hmm… it might be a good idea to do this for allocb()’s that are used when looping back mblks sent downstream for promiscuous devices… I can see arguments both way in that case.)
. . .
The text was updated successfully, but these errors were encountered: