https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292759

Zhenlei Huang <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|Affects Only Me             |Affects Some People
             Status|New                         |In Progress
           Assignee|[email protected]             |[email protected]

--- Comment #16 from Zhenlei Huang <[email protected]> ---
(In reply to vova from comment #15)
> Not sure what you ment under "a new kind of **promiscuous mode**"

Current promiscuous mode reads, the NIC accepts any packets it receives. That
is to say, any frames, tagged or not, destined for us or not, or event bad
frames ( wrong CRCs, em(4) has a knob for that ) should be passed in. That
implies `allmulti` and `-vlanhwfilter`.

"a new kind of **promiscuous mode**" or "a new type of **promiscuous mode**",
shall be `allunicast` if I name it. It hints the driver whether the unicast
frames not destined for us should be accepted or dropped.

> I am not sure, dimention is already here as "vlanfilter", 
> thinking if these two dimentions are intersecting:

> -promisc ->> filters out non mine frames (these that as in ether dst not my 
> address)
>     parametrized by: my MAC(s) when ON
>     clearly required to be OFF for bridge functioning, as it forwards packates

> vlanhwfilter ->> filters out VLANs I am not interested in  
>     parametrized by: my VLAN(s)
>     for bridge it is fine to be either ON or OFF as far as VLAN(s) are 
> propagated

> for me sounds more logical not connect one to another.

If we have `allunicast` mode, then bridge(4) can benefits it from putting
member interface into `allunicast` and `allmulti` mode, while not loosing the
capability to let member interfaces do vlan filtering when `vlanhwfilter` is
available.

I'm sure how many people will be interested with that idea. I can prototype it
on if_em(4) when I have spare time. Are you willing to test it ? 

BTW, I'd like to give your credentials since you have tested the patch to fix
setting the promisc mode of if_em(4). Does `[email protected]` looks good to you, or
you are willing to use the real name?

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to