From: Daniel Borkmann <firstname.lastname@example.org> To: Jesper Dangaard Brouer <email@example.com> Cc: Lorenzo Bianconi <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Andrew Morton <email@example.com> Subject: Re: [PATCH v3 bpf-next] net: veth: alloc skb in bulk for ndo_xdp_xmit Date: Thu, 4 Feb 2021 16:43:10 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On 2/4/21 10:05 AM, Jesper Dangaard Brouer wrote: [...] > It was Andrew (AKPM) that wanted the API to either return the requested > number of objects or fail. I respected the MM-maintainers request at > that point, even-though I wanted the other API as there is a small > performance advantage (not crossing page boundary in SLUB). > > At that time we discussed it on MM-list, and I see his/the point: > If API can allocate less objs than requested, then think about how this > complicated the surrounding code. E.g. in this specific code we already > have VETH_XDP_BATCH(16) xdp_frame objects, which we need to get 16 SKB > objects for. What should the code do if it cannot get 16 SKBs(?). Right, I mentioned the error handling complications above wrt < n_skb case. I think iff this ever gets implemented and there's a need, it would probably be best to add a new flag like __GFP_BULK_BEST_EFFORT to indicate that it would be okay to return x elements with x being in (0, size], so that only those callers need to deal with this, and all others can expect [as today] that != 0 means all #size elements were bulk alloc'ed. Thanks, Daniel
prev parent reply other threads:[~2021-02-04 15:44 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-29 22:04 Lorenzo Bianconi 2021-01-31 14:16 ` Toshiaki Makita 2021-02-02 14:14 ` Jesper Dangaard Brouer 2021-02-04 0:10 ` patchwork-bot+netdevbpf 2021-02-04 0:14 ` Daniel Borkmann 2021-02-04 9:05 ` Jesper Dangaard Brouer 2021-02-04 15:43 ` Daniel Borkmann [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v3 bpf-next] net: veth: alloc skb in bulk for ndo_xdp_xmit' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).