Thanks for the review Ben,


> This is a lot of code, but it looks well crafted.  I only have a few
> comments.
>
> dpif-linux.c
> ------------
>
> The comment on dpif_linux_refresh_channels() mentions dpif->channels,
> which no longer exists
>


Fixed,



> It looks like there are always 'n_handlers' of both handlers and
> epolls in a given struct dpif_linux.  Is there a reason that they're
> separate structs?  There's a comment that's extra confusing to me
> here:
> +    int uc_array_size;             /* Size of 'handlers' and
> 'epoll_events'. */
> because there appear to be n_handlers handlers, not uc_array_size
> handlers.
>


Thanks for the good suggestion, I'll adjust accordingly.



>
> I think that here at the end of vport_add_channels(), the [i] should
> be [j] in the epoll_ctl() call:
>     for (j = 0; j < i; j++) {
>         epoll_ctl(dpif->epolls[i].epoll_fd, EPOLL_CTL_DEL,
>                   nl_sock_fd(socksp[j]), NULL);
>         dpif->handlers[j].channels[port_idx].sock = NULL;
>     }
>


Fixed,



> dpif-linux.h
> ------------
>
> I think the comment update here is now wrong because the change to the
> name of the enum was dropped a revision or two back:
> -    const uint32_t *upcall_pid;            /* OVS_VPORT_ATTR_UPCALL_PID.
> */
> +    const uint32_t *upcall_pids;           /* OVS_VPORT_ATTR_UPCALL_PIDS.
> */
>
> I would move 'n_pids' next to 'upcall_pids' in struct
> dpif_linux_vport, since they are closely related, and probably rename
> one or the other (either 'upcall_pids' to just 'pids' or 'n_pids' to
> 'n_upcall_pids').
>


I'll change the 'n_pids' to 'n_upcall_pids'.  And move it on to of the
'upcall_pids'
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to