Open Source NFP

NFV Approaches Phase 2, With Help from the Linux Foundation

ETSI는 코드를 만들어내지 않지만, 이제 대략적으로 뭘 원하는 지 정리가 되었으니(아직 NFV Group Specifciation 업데이트 된 게 나와야겠지만) 실제 동작하는 코드가 필요하다고. OpenDayLight(ODL)이 그랬던 것처럼 실제로 동작하는 Reference code가 있어야 개발 속도를 높일 수 있다. 문제(?)는 ODL이 그랬던 것처럼 하나의 reference system이 만들어지면 그 reference system과는 다른 것들은 모두 죽어버린다는 것.

이번에도 Linux Foundation이 실질적인 리드를 하기 위해 7/1일에 AT&T, HP, Intel, Linux Foundation 담당자들이 모였다고 한다.Open Source NFV Plans

Reception of unsolicited arp

2.4에서는 unsolicited ARP reply 수신 여부를 커널 빌드 옵션으로 결정했지만 2.6에서는 proc의 arp_accept 값으로 선택할 수 있다.

 

kernel 2.4

#ifdef CONFIG_IP_ACCEPT_UNSOLICITED_ARP
    /* Unsolicited ARP is not accepted by default.
       It is possible, that this option should be enabled for some
       devices (strip is candidate)
     */
    if (n == NULL && 
        arp->ar_op == htons(ARPOP_REPLY) &&
        inet_addr_type(sip) == RTN_UNICAST)
        n = __neigh_lookup(&arp_tbl, &sip, dev, -1);
#endif

kernel 2.6

    if (ipv4_devconf.arp_accept) {
        /* Unsolicited ARP is not accepted by default.
           It is possible, that this option should be enabled for some
           devices (strip is candidate)
         */
        if (n == NULL && 
            arp->ar_op == htons(ARPOP_REPLY) &&
            inet_addr_type(sip VRF_CALL_ARG(dev->vrf)) == RTN_UNICAST)
            n = __neigh_lookup(&arp_tbl, &sip, dev, 1);
    }

ioctl(), the big kernel lock, and 32-bit compatibility [LWN.net]

ioctl(), the big kernel lock, and 32-bit compatibility [LWN.net].

예전에 구현된 ioctl 자체가 BKL(Big Kernel Lock, lock_kernel())을 걸기 때문에 만일 실행되는 ioctl handler가 시간을 많이 소요하면 전체 프로세스들이 커널을 이용하지 못한다는 의미.

Single processor 환경에서는 kernel context로 들어간 순간 어차피 동작할 수 있는 user process가 없으므로 의미가 없지만, multi-processor에서는 상황이 다르다.

관련된 내용 : http://unix.stackexchange.com/questions/4711/what-is-the-difference-between-ioctl-unlocked-ioctl-and-compat-ioctl

좀더 자세히 보면 fs의 method중 ioctl이 삭제되고 unlocked_ioctl로 대체되었다. 그리고 application에서 ioctl을 호출하면 해당 fs의 unlocked_ioctl을 호출한다.

static long vfs_ioctl(struct file *filp, unsigned int cmd,
              unsigned long arg)
{
    int error = -ENOTTY;

    if (!filp->f_op || !filp->f_op->unlocked_ioctl)
        goto out;

    error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
    if (error == -ENOIOCTLCMD)
        error = -EINVAL;
 out:
    return error;
}

참고 : http://forum.falinux.com/zbxe/?document_srl=553645

XFRM – undocumented part in kernel?

XFRM is located deep within the kernel and it isn’t directly visible to the programmer. It is also an undocumented part of the kernel. The standard way of the communication with XFRM is done trough the Netlink Sockets API which is the standard IPC mechanism for various parts of the kernel. More specifically, the part of Netlink of our interest is NETLINK_XFRM. Unfortunately, that part is complex and also undocumented. An additional API does exist. It is called rtnetlink and is a wrapper API for netlink. It is somewhat easier to use and it is somewhat documented. It is a part of iproute2 project

via CROZ / Tech Blog / XFRM Programming.