Eric W. Biederman wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
Patrick McHardy wrote:
Eric W. Biederman wrote:
For the macvlan code do we need to do anything special if we transmit
to a mac we would normally receive? Another unicast mac of the same
nic for example.
That doesn't happen unde
Ben Greear wrote:
> Patrick McHardy wrote:
>
>> Eric W. Biederman wrote:
>>
>>> For the macvlan hash you just use an upper byte. Is that just a
>>> simple starting place, or do we not need a more complex hash.
>>>
>>
>>
>> That gave me an idea, since the default addresses are random
>> anyway
Ben Greear <[EMAIL PROTECTED]> writes:
> Patrick McHardy wrote:
>> Eric W. Biederman wrote:
>
>>> For the macvlan code do we need to do anything special if we transmit
>>> to a mac we would normally receive? Another unicast mac of the same
>>> nic for example.
>>
>> That doesn't happen under norm
Patrick McHardy wrote:
Eric W. Biederman wrote:
For the macvlan code do we need to do anything special if we transmit
to a mac we would normally receive? Another unicast mac of the same
nic for example.
That doesn't happen under normal circumstances. I don't believe
it would work.
Assumin
Patrick McHardy wrote:
Eric W. Biederman wrote:
For the macvlan hash you just use an upper byte. Is that just a
simple starting place, or do we not need a more complex hash.
That gave me an idea, since the default addresses are random
anyway I'm now using an incrementing counter for the up
Eric W. Biederman wrote:
For the macvlan hash you just use an upper byte. Is that just a
simple starting place, or do we not need a more complex hash.
That gave me an idea, since the default addresses are random
anyway I'm now using an incrementing counter for the upper byte.
-
To unsubsc
Eric W. Biederman wrote:
Patrick McHardy <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
I'm trying to understand what the point of this patch is.
In once sense I find the concept of filtering and listening for multiple
mac addresses very interesting, especially if we could break
[EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Thu, 21 Jun 2007 13:08:12 -0600
>
>> However this just seems to allow a card to decode multiple mac
>> addresses which in some oddball load balancing configurations may
>> actually be useful, but it seems fairly limited
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> I'm trying to understand what the point of this patch is.
>>
>> In once sense I find the concept of filtering and listening for multiple
>> mac addresses very interesting, especially if we could break out different
>> stream
Eric W. Biederman wrote:
I'm trying to understand what the point of this patch is.
In once sense I find the concept of filtering and listening for multiple
mac addresses very interesting, especially if we could break out different
streams of traffic by destination mac address into separate netwo
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Thu, 21 Jun 2007 13:08:12 -0600
> However this just seems to allow a card to decode multiple mac addresses
> which in some oddball load balancing configurations may actually be
> useful, but it seems fairly limited.
>
> Do you have a specific use
Patrick McHardy <[EMAIL PROTECTED]> writes:
> These two patches contain a first short at secondary unicast address support.
> I'm still working on converting macvlan as an example, but since I'm about to
> leave for tonight I thougth I'd get them out for some comments now.
>
> The patch adds two n
These two patches contain a first short at secondary unicast address support.
I'm still working on converting macvlan as an example, but since I'm about to
leave for tonight I thougth I'd get them out for some comments now.
The patch adds two new functions dev_unicast_add and dev_unicast_delete to
13 matches
Mail list logo
