Kubernetes插件:Intel sriov-cni插件简介/修改

本文介绍了Intel sriov-cni插件,这是一种使容器直接使用物理机SR-IOV功能的CNI插件,详细解析了sriov-cni的核心功能及代码,并针对存在的问题提出了修改方案,包括dpdk配置处理、容器识别VF配置和对PF的支持。还分享了作者的修改版实现。
摘要由CSDN通过智能技术生成

github bloghttps://xftony.github.io

sriov-cni简介

sriov-cni是hustcat/sriov-cni开发的一种容器网络插件(Container Network Interface),它使得容器可以直接使用物理机中扩展出来的VF(virtual functions)。Intel在此基础上,为其添加了dpdk功能。本文介绍的sriov-cni的版本为Intel版,修改也是基于Intel版本进行的修改。

sriov-cni代码简介

sriov-cni主要通过调用netlink包将vf修改到容器的namespace下,使得VF可以被容器直接调用。其中VF是指支持SRIOV的物理网卡所虚拟出的一个“网卡”或者说虚出来的一个实例,它会以一个独立网卡的形式呈现出来,每一个VF有它自己独享的PCI配置区域,并且可能与其他VF共享着同一个物理资源(公用同一个物理网口)
根据cni的标准定义两个函数cmdAdd和cmdDel,分别用于VF的添加和删除skel.PluginMain(cmdAdd, cmdDel)
cmdAdd和cmdDel基本是一对反过程,所以这里就只简单介绍一下cmdAdd函数。

 func cmdAdd(args *skel.CmdArgs) error {
    n, err := loadConf(args.StdinData) // 将输入参数转化为NetConf变量n
    if err != nil {
        return fmt.Errorf("failed to load netconf: %v", err)
    }
    // 获取container的net命名空间,args.Netns是container的在host中的网络命名空间路径
    netns, err := ns.GetNS(args.Netns)
    if err != nil {
        return fmt.Errorf("failed to open netns %q: %v", netns, err)
    }
    defer netns.Close()

    if n.IF0NAME != "" {
        args.IfName = n.IF0NAME
    }
    // 核心函数,配置VF,将VF移动到container的命名空间
    if err = setupVF(n, n.IF0, args.IfName, args.ContainerID, netns); err != nil {
        return fmt.Errorf("failed to set up pod interface %q from the device %q: %v", args.IfName, n.IF0, err)
    }

    // 在DPDK 和L2模式下, 无需调用IPAM进行IP分配
    var result *types.Result
    if n.DPDKMode != false || n.L2Mode 
  • 0
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Another example is the SRIOV_NET_VF resource class, which is provided by SRIOV-enabled network interface cards. In the case of multiple SRIOV-enabled NICs on a compute host, different qualitative traits may be tagged to each NIC. For example, the NIC called enp2s0 might have a trait “CUSTOM_PHYSNET_PUBLIC” indicating that the NIC is attached to a physical network called “public”. The NIC enp2s1 might have a trait “CUSTOM_PHYSNET_INTRANET” that indicates the NIC is attached to the physical network called “Intranet”. We need a way of representing that these NICs each provide SRIOV_NET_VF resources but those virtual functions are associated with different physical networks. In the resource providers data modeling, the entity which is associated with qualitative traits is the resource provider object. Therefore, we require a way of representing that the SRIOV-enabled NICs are themselves resource providers with inventories of SRIOV_NET_VF resources. Those resource providers are contained on a compute host which is a resource provider that has inventory records for other types of resources such as VCPU, MEMORY_MB or DISK_GB. This spec proposes that nested resource providers be created to allow for distinguishing details of complex components of some resource providers. During review the question came up about “rolling up” amounts of these nested providers to the root level. Imagine this scenario: I have a NIC with two PFs, each of which has only 1 VF available, and I get a request for 2 VFs without any traits to distinguish them. Since there is no single resource provider that can satisfy this request, it will not select this root provider, even though the root provider “owns” 2 VFs. This spec does not propose any sort of “rolling up” of inventory, but this may be something to consider in the future. If it is an idea that has support, another BP/spec can be created then to add this behavior.
07-23
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值