Thank you very much. So if I set up three systems, M5 will automatically set their mac addresses to be 00:90:00:00:00:01, 00:90:00:00:00:02 and 00:90:00:00:00:03, respectively. Right?
Xin ---- Original message ---- >Date: Fri, 7 Dec 2007 14:55:45 -0500 (EST) >From: Nathan Binkert <[EMAIL PROTECTED]> >Subject: Re: [m5-users] issues on switch model for cluster >To: M5 users mailing list <[email protected]> > >They're in the python code in src/python/m5/params.py, but as Ali said, >your switch model should not use that information and should autodiscover >the information. > >> What I asked is how M5 sets the mac addresses and what are >> the unique values(ARP table). I didn't find it in the M5 >> source codes. >> >> Xin >> >> ---- Original message ---- >>> Date: Thu, 6 Dec 2007 23:06:20 -0500 >>> From: Ali Saidi <[EMAIL PROTECTED]> >>> Subject: Re: [m5-users] issues on switch model for cluster >>> To: M5 users mailing list <[email protected]> >>> >>> M5 sets the mac addresses automatically to be unique values. The >>> machines get each others MAC addresses through ARP discovery as they >>> would in any real system. Like I said, if you implement the IEEE >>> 802.1D bridging spec, it will all just work. >>> >>> Ali >>> >>> On Dec 6, 2007, at 10:00 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: >>> >>>> The point is who sets those MAC address. The M5 simulator or >>>> users? I know the IP addresses are set by users in .rcS files. >>>> In the original M5, does each packet contain the destination >>>> mac address? Could you tell me where a packet is created >>>> in M5 source files? Thanks a lot. >>>> >>>> Xin >>>> >>>> ---- Original message ---- >>>>> Date: Thu, 6 Dec 2007 20:36:10 -0500 >>>>> From: Ali Saidi <[EMAIL PROTECTED]> >>>>> Subject: Re: [m5-users] issues on switch model for cluster >>>>> To: M5 users mailing list <[email protected]> >>>>> >>>>> The correct way is the MAC address, and it's always the mac address. >>>>> The IEEE 802.1D specification has a section on ethernet switches that >>>>> describes the process. >>>>> >>>>> Ali >>>>> >>>>> On Dec 6, 2007, at 7:19 PM, <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> Actually, the EtherLink model can be completely replaced >>>>>> by the EtherSwitch model. The topology is looked as follows: >>>>>> ------------------------- >>>>>> System1--EtherInt1-|-Interface1--Interface2-|-EtherInt2--System2 >>>>>> | \ / | >>>>>> | \ / | >>>>>> | Interface3 | >>>>>> | | | >>>>>> ----------|---------------- >>>>>> EtherInt3 >>>>>> | >>>>>> System3 >>>>>> >>>>>> The above box is the switch model. The peer of EtherInt(i) is >>>>>> set to be Interface(i) and Interfaces in the box are >>>>>> interconnected with Links instead of EtherLinks. >>>>>> In your switch model, even though there are N EtherInts in >>>>>> the box and they are connected via Etherlinks from/to >>>>>> outside, some kind of route procedure is still needed. >>>>>> When the packet arrive at the EtherInt in the switch model, >>>>>> how can you determine which port is appropriate? I think >>>>>> the only way is to find the destination information from >>>>>> the packet,no matter mac address or ip address. >>>>>> So the question is how to get the destination information >>>>>> from packet. >>>>>> >>>>>> Xin >>>>>> >>>>>> ---- Original message ---- >>>>>>> Date: Thu, 6 Dec 2007 11:39:27 -0500 >>>>>>> From: Ali Saidi <[EMAIL PROTECTED]> >>>>>>> Subject: Re: [m5-users] issues on switch model for cluster >>>>>>> To: M5 users mailing list <[email protected]> >>>>>>> >>>>>>> >>>>>>> On Dec 6, 2007, at 11:06 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have created an EtherSwitch model to replace the EtherLink. >>>>>>>> However, I got two problems: >>>>>>>> >>>>>>>> 1) In original EtherLink model, each Interface has only one >>>>>>>> txlink, so when Interface::recvPacket(packet) is called by >>>>>>>> its peer, txlink->transmit(packet) is returned. But in >>>>>>>> the EtherSwitch model, each Interface has N-1 txlinks(N is >>>>>>>> # of systems), so function recvPacket(packet) must >>>>>>>> determine >>>>>>>> which txlink is needed to transmit the packet. >>>>>>> The idea is that each two endpoints should have an EtherInt. So >>>>>>> each >>>>>>> system will have an EtherInt and then the switch should have a >>>>>>> separate EtherInt for each "port" that exists on the switch. The >>>>>>> probably should be connected with an EtherLink. >>>>>>> >>>>>>>> I tried to >>>>>>>> find the destination information in the packet. I looked >>>>>>>> through base/inet.hh and found the function dst() can >>>>>>>> return >>>>>>>> the destination address, so I wrote the following codes: >>>>>>>> IpPtr p = IpPtr(packet); >>>>>>>> uint32_t ip_address = p->dst(); >>>>>>>> But the simulator exited with error when it ran the >>>>>>>> above codes. Can anyone know how to get the destination >>>>>>>> information from the packet? >>>>>>> You should read the IEEE 802.1D ethernet standard. Not all packets >>>>>>> transfered across ethernet are IP packets. You need to route >>>>>>> based on >>>>>>> MAC addresses, not on IP addresses. The switch model needs to >>>>>>> keep a >>>>>>> list of MAC addresses behind each port and then when it receives a >>>>>>> packet it needs to find the appropriate port and send the packet to >>>>>>> it. To be complete the model also needs to detect when no port >>>>>>> exists >>>>>>> and respond appropriately. >>>>>>> >>>>>>>> >>>>>>>> 2) similar to the above problem. In original EtherLink model, >>>>>>>> when Interface::isBusy() is called, it just returns >>>>>>>> txlink->busy() since it has only one txlink. But in the >>>>>>>> EtherSwitch model, isBusy doesn't know which txlink >>>>>>>> is needed to transmit the packet and the worse is no packet >>>>>>>> can be used to determine the destination. One feasible >>>>>>>> solution is make sure all txlinks are free before a packet >>>>>>>> is transmitted although only one txlink is used. My >>>>>>>> question is how to modify the original code in order to >>>>>>>> replace isBusy() by isBusy(packet). >>>>>>> I think this will be more clear when you read the above >>>>>>> specification, >>>>>>> but the architecture should look something like this: >>>>>>> http://zeep.eecs.umich.edu/~saidi/etherswitch.pdf >>>>>>> >>>>>>> Ali >>>>>>> >>>>>>> _______________________________________________ >>>>>>> m5-users mailing list >>>>>>> [email protected] >>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>>>> _______________________________________________ >>>>>> m5-users mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>>>> >>>>> >>>>> _______________________________________________ >>>>> m5-users mailing list >>>>> [email protected] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>> _______________________________________________ >>>> m5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>>> >>> >>> _______________________________________________ >>> m5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >_______________________________________________ >m5-users mailing list >[email protected] >http://m5sim.org/cgi-bin/mailman/listinfo/m5-users _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
