Kubernetes插件:SRIOV-CNI获取配置信息小脚本

Github-blog
CSDN-blog

注意 本文提供的脚本是针对本人之前修改的sriov插件的哈。

sriov-cni简介

sriov-cni是hustcat/sriov-cni开发的一种容器网络插件(Container Network Interface),它使得容器可以直接使用物理机中扩展出来的VF(virtual functions)。Intel在此基础上,为其添加了dpdk功能。本人在Intel版本的基础上进行了修改,对应的版本是2017.10.12,具体commit为f45d68b638df76261170bd585fb4014b99990548。 具体修改如下:

1、保存dpdk配置文件和开启dpdk驱动的代码顺序对调,保证在启动更新成功的情况下才会保存配置文件;
2、配置文件路径添加一级容器网络命名空间ID,从而使得容器内可以识别自身的配置文件;
3、添加netconf的配置保存;
4、类似VF,添加setupPF(),实现流程与setupVF()基本一致。

sriov修改详细介绍

配置文件虽然都进行了保存,但是每次读取查找还是不够便捷,因此又写了个小脚本进行配置信息的查询(portName, isDPDKmode, pciAddress),可以直接放到/usr/bin/下,当个小命令用。
例如:

root@xftony:~# mv getpci.py /usr/bin/getpci
root@xftony:~# chmod a+x /usr/bin/getpci

之后就可以直接使用了。

root@xftony:~# cat getpci.py
#!/usr/bin/python2.7
import os
import json
import optparse

def getNameSpace():
    nsFile = "/proc/1/ns/net"
    nsLink = os.readlink(nsFile)
    ns = nsLink[5:-1]
    return ns

def getPci(path):
    ns = getNameSpace()
    confPath = os.path.join(path, ns)
    if not os.path.exists(confPath) :    
        print "can not find the Dir: %s"%confPath
        return
    fileList = os.listdir(confPath)

    portList={}

    for file in fileList:
        if os.path.splitext(file)[1] != '.json':
            continue
        portNew = {}
        filePath = os.path.join(confPath, file)
        fileTime = os.stat(filePath).st_ctime 
        fd = open(filePath, 'r')   
        line = fd.read()
        try:
            dic = json.loads(line)
        except ValueError, e :
            print filePath, "can not be loaded as json", e
        portName = dic.get("if0name") 
        if not portName:
            portName = dic.get("if0name") 
            print filePath,"can not find the ifname"
        pciAddr = dic.get("pci_addr")
        if not pciAddr:
            print filePath,"can not find the pci"
            continue
        isDPDKMode = dic.get("DPDKMode")
        portNew["portName"],portNew["pciAddr"],portNew["isDPDKMode"],portNew["ctime"]= portName,pciAddr,"false",fileTime

        if isDPDKMode :
            portNew["isDPDKMode"] = "true"

        if portName not in portList.keys():
            portList[portName] = portNew
        else:
            oldTime = portList.get(portName).get("ctime")
            if fileTime > oldTime:
                portList.pop(portName)
                portList[portName] = portNew
    return portList

def printPortList(portList):
    for portName in portList.keys():
        print ("portName:{:<10} isDPDKMode:{:<8}PCI:{:<}".format(portName,portList.get(portName).get("isDPDKMode"),portList.get(portName).get("pciAddr")))

if __name__  == "__main__":
    usage = "usage: %prog [options] arg"
    parser = optparse.OptionParser(usage)
    parser.add_option("-p", "--path", dest="path", help="the dir to the confFile, default is \"/opt/pci\" ", default = "/opt/pci")
    options, args = parser.parse_args()
    portList = getPci(options.path)
    if not portList:
        print "can not find any PCI information in ", options.path
    else:
        printPortList(portList)   

以上~

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 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、付费专栏及课程。

余额充值