Thanks Ethan and Alex (and Ronny). I applied this to master and
backported it to branch-2.3, branch-2.1, and branch-2.0.
On Thu, Feb 12, 2015 at 12:33:10PM -0800, Ethan Jackson wrote:
> Solution seems clean, I'm happy with this as well.
>
> Acked-by: Ethan Jackson <et...@nicira.com>
>
>
> On Thu, Feb 12, 2015 at 11:02 AM, Alex Wang <al...@nicira.com> wrote:
> > Looks good to me,
> >
> > /* A MAC learning table entry.
> >> - * Guarded by owning 'mac_learning''s rwlock */
> >> + * Guarded by owning 'mac_learning''s rwlock. */
> >> struct mac_entry {
> >> struct hmap_node hmap_node; /* Node in a mac_learning hmap. */
> >> time_t expires; /* Expiration time. */
> >> @@ -47,14 +108,30 @@ struct mac_entry {
> >> uint16_t vlan; /* VLAN tag. */
> >>
> >> /* The following are marked guarded to prevent users from iterating
> >> over or
> >> - * accessing a mac_entry without hodling the parent mac_learning
> >> rwlock. */
> >> + * accessing a mac_entry without holding the parent mac_learning
> >> rwlock. */
> >> struct ovs_list lru_node OVS_GUARDED; /* Element in 'lrus' list. */
> >>
> >> - /* Learned port. */
> >> - union {
> >> - void *p;
> >> - ofp_port_t ofp_port;
> >> - } port OVS_GUARDED;
> >> + /* Learned port.
> >> + *
> >> + * The client-specified data is mlport->port. */
> >> + struct mac_learning_port *mlport;
> >>
> >
> >
> > Simple C question, why don't we need to forward declare the struct
> > 'mac_learning_port'?
> > _______________________________________________
> > dev mailing list
> > dev@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
