nfp_net_alloc(9)
π nfp_net_alloc(9) β Kernel API Manual, but make it make sense π
okay bestie, so this one is nfp_net_alloc, straight out of the kernel API manual, and it's literally the "build me a net device" function. Buckle up π
β¨ NAME β¨
nfp_net_alloc β Allocate netdev and related structure
(yeah that's it, that's the whole name section, she's concise π)
π¦ SYNOPSIS π¦
struct nfp_net * nfp_net_alloc (struct pci_dev *pdev , const struct
nfp_dev_info *dev_info , void __iomem *ctrl_bar , bool needs_netdev ,
unsigned int max_tx_rings , unsigned int max_rx_rings );
like, six things go in, one struct nfp_net * comes out, we love a function with commitment π
πΈ ARGUMENTS πΈ
pdevβ the PCI device. your actual physical friend in the machine πdev_infoβ the NFP ASIC params. the lore, the specs, the whole personality sheet.ctrl_barβ PCI IOMEM with vNIC config memory. this is where the config brain lives,__iomemand all, no touching it with your bare pointers πneeds_netdevβ aboolthat answers the question of the day: are we allocating a netdev for this vNIC or not? yes/no, that's the vibe check.max_tx_ringsβ Maximum number of TX rings supported by device. cap it, know it, respect it πmax_rx_ringsβ Maximum number of RX rings supported by device. same energy, receiving side, iconic.
π₯ DESCRIPTION π₯
So what this function does is it allocates a netdev device and fills in the initial part of the struct nfp_net structure. like, first-pass setup, the beginning of the struct gets its little values, very main character energy.
And here's the twist, bestie: in case of control device, the nfp_net structure is allocated without the netdev. no netdev. none. that's the whole plot point for control devices β needs_netdev was there for a reason, slay π
β RETURN β
Returns the NFP Net device structure β or ERR_PTR on error π so bestie please, check it. don't be out here dereferencing without a vibe check, ERR_PTR is a trap not a gift π
fr fr: an error comes back asERR_PTR, notNULL. check properly,IS_ERRand all that. we don't rawdog error handling in this house π
π§ SEE ALSO π§
the kernel file, held down loyally:
./drivers/net/ethernet/netronome/nfp/nfp_net_common.c
and the whole friend group, alphabetically unbothered, all present and accounted for π:
nfp_net_get_fw_version(9),nfp_net_reconfig_post(9),__nfp_net_reconfig(9),nfp_net_mbox_reconfig(9),nfp_net_irqs_alloc(9),nfp_net_irqs_assign(9),nfp_net_irqs_disable(9),nfp_net_irq_rxtx(9),nfp_net_read_link_status(9),nfp_net_irq_lsc(9),nfp_net_irq_exn(9),nfp_net_aux_irq_request(9),nfp_net_aux_irq_free(9),nfp_net_vecs_init(9),nfp_net_rss_write_itbl(9),nfp_net_rss_write_key(9),nfp_net_coalesce_write_cfg(9),nfp_net_write_mac_addr(9),nfp_net_clear_config_and_disable(9),nfp_net_set_config_and_enable(9),nfp_net_close_stack(9),nfp_net_close_free_all(9),nfp_net_netdev_close(9),nfp_net_open_stack(9),nfp_net_info(9),nfp_net_free(9),nfp_net_rss_key_sz(9),nfp_net_rss_init(9),nfp_net_irqmod_init(9),nfp_net_init(9),nfp_net_clean(9)
and that's the page, diva π«Ά β source ./drivers/net/ethernet/netrono... (the footer got truncated, not me, iykyk π), dated October 2026, page still nfp_net_alloc(9) because she knows exactly who she is πβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms