Discussion:
[gem5-dev] EthAddr use.
(too old to reply)
Anthony Gutierrez via gem5-dev
2014-05-22 18:28:40 UTC
Permalink
Hello,

Can someone tell me what EthAddr was supposed to be used for? grepping
shows that it isn't really used for anything? I'm curious as to why all the
constructors and methods only operate on data[0]. Is there any reason all 6
bytes are not used?

Thanks,
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
Steve Reinhardt via gem5-dev
2014-05-23 06:11:15 UTC
Permalink
It's an ethernet address (for binding to ethernet NICs). Note that it
(confusingly) corresponds to the python param class called 'EthernetAddr',
which is why grepping just for 'EthAddr' makes it look less used than it is.

Maybe I'm not looking at the same code you are, but I don't see what you're
saying about only operating on data[0].

Steve



On Thu, May 22, 2014 at 11:28 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
Hello,
Can someone tell me what EthAddr was supposed to be used for? grepping
shows that it isn't really used for anything? I'm curious as to why all the
constructors and methods only operate on data[0]. Is there any reason all 6
bytes are not used?
Thanks,
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Anthony Gutierrez via gem5-dev
2014-05-23 10:49:42 UTC
Permalink
I'll clarify the question. I built a simple Ethernet switch model and
wanted to use EthAddr to store MAC address in the switch table, which would
be a std::map<uint64_t, EthInt*>. Looking at the code it seemed EthAddr was
only used in the NIC, and in that case it only used the ctor that takes in
a string, as well as the uint64_t cast operator, which allowed the NICs to
cast from a string to uint64_t to set their macAddr.

However the other ctors take in either an array or reference to an eth_addr
struct and do initialization like:

*data = *ea;
or
*data = *ea.data

Which is equivalent to: data[0] = ea[0] or data[0] = ea.data[0]. All the
class methods - with the exception of the overloaded uint64_t cast operator
- only utilize data[0] as well:

const uint8_t *bytes() const { return &data[0]; }
uint8_t *bytes() { return &data[0]; }

const uint8_t *addr() const { return &data[0]; }
bool unicast() const { return data[0] == 0x00; }
bool multicast() const { return data[0] == 0x01; }
bool broadcast() const { return data[0] == 0xff; }

I had to modify this class to make it more robust, and I was wondering if
this class was never completed or if this is the intended usage.


Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier


On Fri, May 23, 2014 at 2:11 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
It's an ethernet address (for binding to ethernet NICs). Note that it
(confusingly) corresponds to the python param class called 'EthernetAddr',
which is why grepping just for 'EthAddr' makes it look less used than it is.
Maybe I'm not looking at the same code you are, but I don't see what you're
saying about only operating on data[0].
Steve
On Thu, May 22, 2014 at 11:28 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
Hello,
Can someone tell me what EthAddr was supposed to be used for? grepping
shows that it isn't really used for anything? I'm curious as to why all
the
Post by Anthony Gutierrez via gem5-dev
constructors and methods only operate on data[0]. Is there any reason
all 6
Post by Anthony Gutierrez via gem5-dev
bytes are not used?
Thanks,
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Steve Reinhardt via gem5-dev
2014-05-23 15:05:45 UTC
Permalink
Well that's a very different question ;-).

The bytes() and addr() methods look fine to me; they're just using
'&data[0]' as reverse shorthand for 'data'.

The pointer assignments you show look like bugs. I expect that Nate was
thinking in terms of structs and not arrays and expecting the whole address
to be copied over.

The unicast/multicast/broadcast methods do get used in ns_gige and sinic,
though in the latter case all the places they are used are ifdef'd out.
They're not quite correct either, but sort of close. broadcast() is the
only one that needs to check all the bytes; as far as I can tell,
multicast() should be '(data[0] & 0x01) && !broadcast()' and unicast()
should be '!(data[0] & 0x01)'. Or I suppose you could define multicast()
as '!unicast() && !broadcast()' for minimal redundancy.

Other than that though, it looks reasonable to me,

Steve



On Fri, May 23, 2014 at 3:49 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
I'll clarify the question. I built a simple Ethernet switch model and
wanted to use EthAddr to store MAC address in the switch table, which would
be a std::map<uint64_t, EthInt*>. Looking at the code it seemed EthAddr was
only used in the NIC, and in that case it only used the ctor that takes in
a string, as well as the uint64_t cast operator, which allowed the NICs to
cast from a string to uint64_t to set their macAddr.
However the other ctors take in either an array or reference to an eth_addr
*data = *ea;
or
*data = *ea.data
Which is equivalent to: data[0] = ea[0] or data[0] = ea.data[0]. All the
class methods - with the exception of the overloaded uint64_t cast operator
const uint8_t *bytes() const { return &data[0]; }
uint8_t *bytes() { return &data[0]; }
const uint8_t *addr() const { return &data[0]; }
bool unicast() const { return data[0] == 0x00; }
bool multicast() const { return data[0] == 0x01; }
bool broadcast() const { return data[0] == 0xff; }
I had to modify this class to make it more robust, and I was wondering if
this class was never completed or if this is the intended usage.
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
On Fri, May 23, 2014 at 2:11 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
It's an ethernet address (for binding to ethernet NICs). Note that it
(confusingly) corresponds to the python param class called
'EthernetAddr',
Post by Steve Reinhardt via gem5-dev
which is why grepping just for 'EthAddr' makes it look less used than it is.
Maybe I'm not looking at the same code you are, but I don't see what
you're
Post by Steve Reinhardt via gem5-dev
saying about only operating on data[0].
Steve
On Thu, May 22, 2014 at 11:28 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
Hello,
Can someone tell me what EthAddr was supposed to be used for? grepping
shows that it isn't really used for anything? I'm curious as to why all
the
Post by Anthony Gutierrez via gem5-dev
constructors and methods only operate on data[0]. Is there any reason
all 6
Post by Anthony Gutierrez via gem5-dev
bytes are not used?
Thanks,
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Anthony Gutierrez via gem5-dev
2014-05-23 16:06:43 UTC
Permalink
Ah, I didn't notice the '&' there before. The only changes I had to make
were to broadcast and to the constructors since I extract the MAC from the
packet as an array of uint8_t.

I will probably put the switch model and some changes to EthAddr on the
reviewboard next week then.


Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier


On Fri, May 23, 2014 at 11:05 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
Well that's a very different question ;-).
The bytes() and addr() methods look fine to me; they're just using
'&data[0]' as reverse shorthand for 'data'.
The pointer assignments you show look like bugs. I expect that Nate was
thinking in terms of structs and not arrays and expecting the whole address
to be copied over.
The unicast/multicast/broadcast methods do get used in ns_gige and sinic,
though in the latter case all the places they are used are ifdef'd out.
They're not quite correct either, but sort of close. broadcast() is the
only one that needs to check all the bytes; as far as I can tell,
multicast() should be '(data[0] & 0x01) && !broadcast()' and unicast()
should be '!(data[0] & 0x01)'. Or I suppose you could define multicast()
as '!unicast() && !broadcast()' for minimal redundancy.
Other than that though, it looks reasonable to me,
Steve
On Fri, May 23, 2014 at 3:49 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
I'll clarify the question. I built a simple Ethernet switch model and
wanted to use EthAddr to store MAC address in the switch table, which
would
Post by Anthony Gutierrez via gem5-dev
be a std::map<uint64_t, EthInt*>. Looking at the code it seemed EthAddr
was
Post by Anthony Gutierrez via gem5-dev
only used in the NIC, and in that case it only used the ctor that takes
in
Post by Anthony Gutierrez via gem5-dev
a string, as well as the uint64_t cast operator, which allowed the NICs
to
Post by Anthony Gutierrez via gem5-dev
cast from a string to uint64_t to set their macAddr.
However the other ctors take in either an array or reference to an
eth_addr
Post by Anthony Gutierrez via gem5-dev
*data = *ea;
or
*data = *ea.data
Which is equivalent to: data[0] = ea[0] or data[0] = ea.data[0]. All the
class methods - with the exception of the overloaded uint64_t cast
operator
Post by Anthony Gutierrez via gem5-dev
const uint8_t *bytes() const { return &data[0]; }
uint8_t *bytes() { return &data[0]; }
const uint8_t *addr() const { return &data[0]; }
bool unicast() const { return data[0] == 0x00; }
bool multicast() const { return data[0] == 0x01; }
bool broadcast() const { return data[0] == 0xff; }
I had to modify this class to make it more robust, and I was wondering if
this class was never completed or if this is the intended usage.
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
On Fri, May 23, 2014 at 2:11 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
It's an ethernet address (for binding to ethernet NICs). Note that it
(confusingly) corresponds to the python param class called
'EthernetAddr',
Post by Steve Reinhardt via gem5-dev
which is why grepping just for 'EthAddr' makes it look less used than
it
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
is.
Maybe I'm not looking at the same code you are, but I don't see what
you're
Post by Steve Reinhardt via gem5-dev
saying about only operating on data[0].
Steve
On Thu, May 22, 2014 at 11:28 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
Hello,
Can someone tell me what EthAddr was supposed to be used for?
grepping
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
shows that it isn't really used for anything? I'm curious as to why
all
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
the
Post by Anthony Gutierrez via gem5-dev
constructors and methods only operate on data[0]. Is there any reason
all 6
Post by Anthony Gutierrez via gem5-dev
bytes are not used?
Thanks,
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Steve Reinhardt via gem5-dev
2014-05-23 17:49:57 UTC
Permalink
Great! I'll look forward to that. We've been talking about an Ethernet
switch for so long, it will be nice to finally have one.

Have you thought about adding in the synchronization needed to parallelize
the simulation (separating the simulated hosts across threads)? If not, we
might be able to work on that.

Steve


On Fri, May 23, 2014 at 9:06 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
Ah, I didn't notice the '&' there before. The only changes I had to make
were to broadcast and to the constructors since I extract the MAC from the
packet as an array of uint8_t.
I will probably put the switch model and some changes to EthAddr on the
reviewboard next week then.
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
On Fri, May 23, 2014 at 11:05 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
Well that's a very different question ;-).
The bytes() and addr() methods look fine to me; they're just using
'&data[0]' as reverse shorthand for 'data'.
The pointer assignments you show look like bugs. I expect that Nate was
thinking in terms of structs and not arrays and expecting the whole
address
Post by Steve Reinhardt via gem5-dev
to be copied over.
The unicast/multicast/broadcast methods do get used in ns_gige and sinic,
though in the latter case all the places they are used are ifdef'd out.
They're not quite correct either, but sort of close. broadcast() is the
only one that needs to check all the bytes; as far as I can tell,
multicast() should be '(data[0] & 0x01) && !broadcast()' and unicast()
should be '!(data[0] & 0x01)'. Or I suppose you could define multicast()
as '!unicast() && !broadcast()' for minimal redundancy.
Other than that though, it looks reasonable to me,
Steve
On Fri, May 23, 2014 at 3:49 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
I'll clarify the question. I built a simple Ethernet switch model and
wanted to use EthAddr to store MAC address in the switch table, which
would
Post by Anthony Gutierrez via gem5-dev
be a std::map<uint64_t, EthInt*>. Looking at the code it seemed EthAddr
was
Post by Anthony Gutierrez via gem5-dev
only used in the NIC, and in that case it only used the ctor that takes
in
Post by Anthony Gutierrez via gem5-dev
a string, as well as the uint64_t cast operator, which allowed the NICs
to
Post by Anthony Gutierrez via gem5-dev
cast from a string to uint64_t to set their macAddr.
However the other ctors take in either an array or reference to an
eth_addr
Post by Anthony Gutierrez via gem5-dev
*data = *ea;
or
*data = *ea.data
Which is equivalent to: data[0] = ea[0] or data[0] = ea.data[0]. All
the
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
class methods - with the exception of the overloaded uint64_t cast
operator
Post by Anthony Gutierrez via gem5-dev
const uint8_t *bytes() const { return &data[0]; }
uint8_t *bytes() { return &data[0]; }
const uint8_t *addr() const { return &data[0]; }
bool unicast() const { return data[0] == 0x00; }
bool multicast() const { return data[0] == 0x01; }
bool broadcast() const { return data[0] == 0xff; }
I had to modify this class to make it more robust, and I was wondering
if
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
this class was never completed or if this is the intended usage.
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
On Fri, May 23, 2014 at 2:11 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
It's an ethernet address (for binding to ethernet NICs). Note that
it
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
(confusingly) corresponds to the python param class called
'EthernetAddr',
Post by Steve Reinhardt via gem5-dev
which is why grepping just for 'EthAddr' makes it look less used than
it
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
is.
Maybe I'm not looking at the same code you are, but I don't see what
you're
Post by Steve Reinhardt via gem5-dev
saying about only operating on data[0].
Steve
On Thu, May 22, 2014 at 11:28 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
Hello,
Can someone tell me what EthAddr was supposed to be used for?
grepping
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
shows that it isn't really used for anything? I'm curious as to why
all
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
the
Post by Anthony Gutierrez via gem5-dev
constructors and methods only operate on data[0]. Is there any
reason
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
all 6
Post by Anthony Gutierrez via gem5-dev
bytes are not used?
Thanks,
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Anthony Gutierrez via gem5-dev
2014-05-23 18:03:06 UTC
Permalink
No I haven't thought about that. I'm not sure what that entails. Do you
have any ideas about this already?


Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier


On Fri, May 23, 2014 at 1:49 PM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
Great! I'll look forward to that. We've been talking about an Ethernet
switch for so long, it will be nice to finally have one.
Have you thought about adding in the synchronization needed to parallelize
the simulation (separating the simulated hosts across threads)? If not, we
might be able to work on that.
Steve
On Fri, May 23, 2014 at 9:06 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
Ah, I didn't notice the '&' there before. The only changes I had to make
were to broadcast and to the constructors since I extract the MAC from
the
Post by Anthony Gutierrez via gem5-dev
packet as an array of uint8_t.
I will probably put the switch model and some changes to EthAddr on the
reviewboard next week then.
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
On Fri, May 23, 2014 at 11:05 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
Well that's a very different question ;-).
The bytes() and addr() methods look fine to me; they're just using
'&data[0]' as reverse shorthand for 'data'.
The pointer assignments you show look like bugs. I expect that Nate
was
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
thinking in terms of structs and not arrays and expecting the whole
address
Post by Steve Reinhardt via gem5-dev
to be copied over.
The unicast/multicast/broadcast methods do get used in ns_gige and
sinic,
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
though in the latter case all the places they are used are ifdef'd out.
They're not quite correct either, but sort of close. broadcast() is
the
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
only one that needs to check all the bytes; as far as I can tell,
multicast() should be '(data[0] & 0x01) && !broadcast()' and unicast()
should be '!(data[0] & 0x01)'. Or I suppose you could define
multicast()
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
as '!unicast() && !broadcast()' for minimal redundancy.
Other than that though, it looks reasonable to me,
Steve
On Fri, May 23, 2014 at 3:49 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
I'll clarify the question. I built a simple Ethernet switch model and
wanted to use EthAddr to store MAC address in the switch table, which
would
Post by Anthony Gutierrez via gem5-dev
be a std::map<uint64_t, EthInt*>. Looking at the code it seemed
EthAddr
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
was
Post by Anthony Gutierrez via gem5-dev
only used in the NIC, and in that case it only used the ctor that
takes
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
in
Post by Anthony Gutierrez via gem5-dev
a string, as well as the uint64_t cast operator, which allowed the
NICs
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
to
Post by Anthony Gutierrez via gem5-dev
cast from a string to uint64_t to set their macAddr.
However the other ctors take in either an array or reference to an
eth_addr
Post by Anthony Gutierrez via gem5-dev
*data = *ea;
or
*data = *ea.data
Which is equivalent to: data[0] = ea[0] or data[0] = ea.data[0]. All
the
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
class methods - with the exception of the overloaded uint64_t cast
operator
Post by Anthony Gutierrez via gem5-dev
const uint8_t *bytes() const { return &data[0]; }
uint8_t *bytes() { return &data[0]; }
const uint8_t *addr() const { return &data[0]; }
bool unicast() const { return data[0] == 0x00; }
bool multicast() const { return data[0] == 0x01; }
bool broadcast() const { return data[0] == 0xff; }
I had to modify this class to make it more robust, and I was
wondering
Post by Anthony Gutierrez via gem5-dev
if
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
this class was never completed or if this is the intended usage.
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
On Fri, May 23, 2014 at 2:11 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
It's an ethernet address (for binding to ethernet NICs). Note that
it
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
(confusingly) corresponds to the python param class called
'EthernetAddr',
Post by Steve Reinhardt via gem5-dev
which is why grepping just for 'EthAddr' makes it look less used
than
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
it
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
is.
Maybe I'm not looking at the same code you are, but I don't see
what
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
you're
Post by Steve Reinhardt via gem5-dev
saying about only operating on data[0].
Steve
On Thu, May 22, 2014 at 11:28 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
Hello,
Can someone tell me what EthAddr was supposed to be used for?
grepping
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
shows that it isn't really used for anything? I'm curious as to
why
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
all
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
the
Post by Anthony Gutierrez via gem5-dev
constructors and methods only operate on data[0]. Is there any
reason
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
all 6
Post by Anthony Gutierrez via gem5-dev
bytes are not used?
Thanks,
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Steve Reinhardt via gem5-dev
2014-05-30 19:58:31 UTC
Permalink
We have some ideas... perhaps more importantly, we also have a summer
intern who's lined up to work on this. Step 1 was going to be "write a
switch model", but if we can use yours to skip that step and go right to
"parallelize the simulation", seems like that would be a win-win.

Steve



On Fri, May 23, 2014 at 11:03 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
No I haven't thought about that. I'm not sure what that entails. Do you
have any ideas about this already?
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
On Fri, May 23, 2014 at 1:49 PM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
Great! I'll look forward to that. We've been talking about an Ethernet
switch for so long, it will be nice to finally have one.
Have you thought about adding in the synchronization needed to
parallelize
Post by Steve Reinhardt via gem5-dev
the simulation (separating the simulated hosts across threads)? If not,
we
Post by Steve Reinhardt via gem5-dev
might be able to work on that.
Steve
On Fri, May 23, 2014 at 9:06 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
Ah, I didn't notice the '&' there before. The only changes I had to
make
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
were to broadcast and to the constructors since I extract the MAC from
the
Post by Anthony Gutierrez via gem5-dev
packet as an array of uint8_t.
I will probably put the switch model and some changes to EthAddr on the
reviewboard next week then.
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
On Fri, May 23, 2014 at 11:05 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
Well that's a very different question ;-).
The bytes() and addr() methods look fine to me; they're just using
'&data[0]' as reverse shorthand for 'data'.
The pointer assignments you show look like bugs. I expect that Nate
was
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
thinking in terms of structs and not arrays and expecting the whole
address
Post by Steve Reinhardt via gem5-dev
to be copied over.
The unicast/multicast/broadcast methods do get used in ns_gige and
sinic,
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
though in the latter case all the places they are used are ifdef'd
out.
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
They're not quite correct either, but sort of close. broadcast() is
the
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
only one that needs to check all the bytes; as far as I can tell,
multicast() should be '(data[0] & 0x01) && !broadcast()' and
unicast()
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
should be '!(data[0] & 0x01)'. Or I suppose you could define
multicast()
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
as '!unicast() && !broadcast()' for minimal redundancy.
Other than that though, it looks reasonable to me,
Steve
On Fri, May 23, 2014 at 3:49 AM, Anthony Gutierrez via gem5-dev <
Post by Anthony Gutierrez via gem5-dev
I'll clarify the question. I built a simple Ethernet switch model
and
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
wanted to use EthAddr to store MAC address in the switch table,
which
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
would
Post by Anthony Gutierrez via gem5-dev
be a std::map<uint64_t, EthInt*>. Looking at the code it seemed
EthAddr
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
was
Post by Anthony Gutierrez via gem5-dev
only used in the NIC, and in that case it only used the ctor that
takes
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
in
Post by Anthony Gutierrez via gem5-dev
a string, as well as the uint64_t cast operator, which allowed the
NICs
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
to
Post by Anthony Gutierrez via gem5-dev
cast from a string to uint64_t to set their macAddr.
However the other ctors take in either an array or reference to an
eth_addr
Post by Anthony Gutierrez via gem5-dev
*data = *ea;
or
*data = *ea.data
Which is equivalent to: data[0] = ea[0] or data[0] = ea.data[0].
All
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
the
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
class methods - with the exception of the overloaded uint64_t cast
operator
Post by Anthony Gutierrez via gem5-dev
const uint8_t *bytes() const { return &data[0]; }
uint8_t *bytes() { return &data[0]; }
const uint8_t *addr() const { return &data[0]; }
bool unicast() const { return data[0] == 0x00; }
bool multicast() const { return data[0] == 0x01; }
bool broadcast() const { return data[0] == 0xff; }
I had to modify this class to make it more robust, and I was
wondering
Post by Anthony Gutierrez via gem5-dev
if
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
this class was never completed or if this is the intended usage.
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
On Fri, May 23, 2014 at 2:11 AM, Steve Reinhardt via gem5-dev <
Post by Steve Reinhardt via gem5-dev
It's an ethernet address (for binding to ethernet NICs). Note
that
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
it
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
(confusingly) corresponds to the python param class called
'EthernetAddr',
Post by Steve Reinhardt via gem5-dev
which is why grepping just for 'EthAddr' makes it look less used
than
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
it
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
is.
Maybe I'm not looking at the same code you are, but I don't see
what
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
you're
Post by Steve Reinhardt via gem5-dev
saying about only operating on data[0].
Steve
On Thu, May 22, 2014 at 11:28 AM, Anthony Gutierrez via gem5-dev
<
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Hello,
Can someone tell me what EthAddr was supposed to be used for?
grepping
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
shows that it isn't really used for anything? I'm curious as to
why
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
all
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
the
Post by Anthony Gutierrez via gem5-dev
constructors and methods only operate on data[0]. Is there any
reason
Post by Steve Reinhardt via gem5-dev
Post by Anthony Gutierrez via gem5-dev
Post by Steve Reinhardt via gem5-dev
all 6
Post by Anthony Gutierrez via gem5-dev
bytes are not used?
Thanks,
Anthony Gutierrez
http://web.eecs.umich.edu/~atgutier
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
http://m5sim.org/mailman/listinfo/gem5-dev
Loading...