Thanks, Ben, Your confirmation is what I want. :)
2012/3/14 Ben Pfaff <b...@nicira.com>
> Yes, that's correct. In a switch, packets can come in and go out on
> the same set of ports, so there is only one list. Why do you expect
> differently?
>
> On Tue, Mar 13, 2012 at 06:20:21PM +0800, Jingfei Hu wrote:
> > Ben, Sorry for the delay.
> > In the struct dp_netdev, there are two members, struct dp_netdev_port
> > *ports[MAX_PORTS] and struct list port_list, which mean the ports of this
> > datapath, also a switch. And in the snippet code of function
> > dpif_netdev_run():
> > --------------------------------------------------------------------
> > LIST_FOR_EACH (port, node, &dp->port_list)
> > --------------------------------------------------------------------
> >
> > so dp->port_list represents the input ports of the datapath. Then
> following
> > the call stack, here is the code of function dp_netdev_output_port():
> > -------------------------------------------------------------------
> > struct dp_netdev_port *p = dp->ports[out_port];
> > if (p) {
> > netdev_send(p->netdev, packet);
> > }
> > ------------------------------------------------------------------
> >
> > So this dp->ports represent the output ports of the datapath. Is that
> > correct?
> >
> > Cheers,
> >
> > Jfhu
> > 2012/3/9 Ben Pfaff <b...@nicira.com>
> >
> > > What is "the output ports list" and "the input ports list"? I don't
> > > know what list (lists?) you mean.
> > >
> > > On Thu, Mar 08, 2012 at 08:35:38PM +0800, HuJingfei wrote:
> > > >
> > > > Thanks, Ben,Exactly speaking, it's the loop of function
> > > > dpif_netdev_run() that does the packets scheduling. Now, I know that
> > > > the next procedure of normal process is: dpif_netdev_run() ->
> > > > dp_netdev_port_input() -> dp_netdev_execute_actions() ->
> > > > dp_netdev_output_port()But what confuses me is that why the output
> > > > ports list is the same with input ports list? Is that scan?
> > > > Cheers,
> > > > Jfhu
> > > > > Date: Wed, 7 Mar 2012 08:00:06 -0800
> > > > > From: b...@nicira.com
> > > > > To: hujingfei...@msn.com
> > > > > CC: discuss@openvswitch.org
> > > > > Subject: Re: [ovs-discuss] Switch architecture of OVS userspace
> switch
> > > > >
> > > > > Since you are specifically interested in the userspace OVS switch,
> you
> > > > > can just follow the process of the loop in dpif_run(). Each
> iteration
> > > > > of the loop fully processes one packet.
> > > > >
> > > > > On Wed, Mar 07, 2012 at 03:56:03PM +0800, HuJingfei wrote:
> > > > > >
> > > > > > Thanks, Ben, I appreciate your help very much.Is there any
> > > > > > documentation or schematic diagram that describes the process
> that a
> > > > > > packet entering the switch's input ports, scheduling, and
> departing
> > > > > > from the switch's output ports? Or there is no such stuff in OVS？
> > > > > > Cheers,
> > > > > > Jfhu> Date: Tue, 6 Mar 2012 21:37:32 -0800
> > > > > > > From: b...@nicira.com
> > > > > > > To: hujingfei...@msn.com
> > > > > > > CC: discuss@openvswitch.org
> > > > > > > Subject: Re: [ovs-discuss] Switch architecture of OVS userspace
> > > switch
> > > > > > >
> > > > > > > On Wed, Mar 07, 2012 at 11:35:57AM +0800, HuJingfei wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks, Ben, All right. However, at least there is a mapping
> > > from the
> > > > > > > > software implementation of a switch to its real component. Is
> > > that
> > > > > > > > right? For example,The struct, dp_netdev, may be mapped to a
> > > switch,
> > > > > > > > because of following mappings:1. member struct
> dp_netdev_queue
> > > > > > > > queues[N_QUEUES] corresponds to actual buffer of a switch,
> every
> > > > > > > > packet from input ports will enter this buffer first, then
> will
> > > be
> > > > > > > > scheduled to go to its destined output port.
> > > > > > >
> > > > > > > No, that's wrong, that's not at all how these queues are used.
> > > These
> > > > > > > queues are used to respond to dpif_recv(). Please read the
> > > > > > > documentation for that function to obtain more insight.
> > > > > > >
> > > > > > > > 2. member struct dp_netdev_port *ports[MAX_PORTS]
> corresponds to
> > > > > > > > actual ports of a switch.
> > > > > > >
> > > > > > > Yes, that is correct.
> > > > > > >
> > > > > > > > Please correct me if I am wrong. Cheers,Jfhu
> > > > > > > > > Date: Tue, 6 Mar 2012 14:17:57 -0800
> > > > > > > > > From: b...@nicira.com
> > > > > > > > > To: hujingfei...@msn.com
> > > > > > > > > CC: discuss@openvswitch.org
> > > > > > > > > Subject: Re: [ovs-discuss] Switch architecture of OVS
> > > userspace switch
> > > > > > > > >
> > > > > > > > > On Tue, Mar 06, 2012 at 11:35:42AM +0800, HuJingfei wrote:
> > > > > > > > > >
> > > > > > > > > > Hi, all,I'm newbie to OVS. I know there are quite a lot
> of
> > > switch
> > > > > > > > > > architectures such as Shared Memory, Shared Medium,
> > > Crossbar, Banyan
> > > > > > > > > > and so on. Could anyone tell me the userspace OVS
> switch's
> > > > > > > > > > architecture please? Forgive me for my stupid question.
> > > Cheers, Jfhu
> > > > > > > > >
> > > > > > > > > It's a piece of software, not a piece of hardware, so it's
> not
> > > > > > > > > meaningful to try to classify it in terms of hardware
> designs.
> > > > > > > >
> > > > > >
> > > >
> > > _______________________________________________
> > > discuss mailing list
> > > discuss@openvswitch.org
> > > http://openvswitch.org/mailman/listinfo/discuss
> > >
>
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
