Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPD 6 feedback from Garrett #3

Open
danmcd opened this issue Jul 31, 2019 · 0 comments
Open

IPD 6 feedback from Garrett #3

danmcd opened this issue Jul 31, 2019 · 0 comments
Assignees

Comments

@danmcd
Copy link
Member

danmcd commented Jul 31, 2019

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.)

. . .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants