en:developers:summits:ottawa-2015
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:developers:summits:ottawa-2015 [2015/02/15 13:38] Robert Copeland fix formatting |
en:developers:summits:ottawa-2015 [2015/02/27 08:03] Johannes Berg |
||
|---|---|---|---|
| Line 40: | Line 40: | ||
| == Notes == | == Notes == | ||
| * netconf recap | * netconf recap | ||
| - | * add sysctl knobs for filtering / route lookup for hotspot 2.0 | + | * add sysctl knobs for client-side filtering (needing route lookup) for hotspot 2.0 |
| * need to do a route lookup in ipv4 for mcast -- can't tell whether something is multicast or unicast without knowing the netmask | * need to do a route lookup in ipv4 for mcast -- can't tell whether something is multicast or unicast without knowing the netmask | ||
| + | * 4 new knobs | ||
| + | * drop-unicast-IPv4-in-multi/broadcast-L2 (even for RFC SHOULD compliance) | ||
| + | * originally suggested code in IP stack broke cluster ip, so sysctl needed | ||
| + | * same for IPv6 | ||
| + | * drop gratuitous ARP | ||
| + | * drop unsolicited NA | ||
| * proxy arp | * proxy arp | ||
| * perceived difficult to add stuff to bridging code | * perceived difficult to add stuff to bridging code | ||
| - | * drop certain unicast frames do it in the IP stack? breaks cluster ip, so unlikely to happen there | ||
| * some feedback from mac80211 on queuing time to improve transmit time | * some feedback from mac80211 on queuing time to improve transmit time | ||
| * new wiki | * new wiki | ||
| Line 61: | Line 66: | ||
| * someone takes stuff from internal tree to send it back upstream | * someone takes stuff from internal tree to send it back upstream | ||
| * is there an alternative that's more permanent? | * is there an alternative that's more permanent? | ||
| - | * linux-next might be a replacement if mac80211-next went into -next | + | * linux-next might be a replacement if mac80211-next went into linux-next |
| * Kalle: we need it because no one has any idea which tree to use | * Kalle: we need it because no one has any idea which tree to use | ||
| * Kalle wants to keep it for forseeable future | * Kalle wants to keep it for forseeable future | ||
| Line 69: | Line 74: | ||
| * intel: build AMSDU for TSO frames | * intel: build AMSDU for TSO frames | ||
| * take one TSO packet, split into AMSDUs | * take one TSO packet, split into AMSDUs | ||
| - | * doing segmentation in TCP stack: have to have some delays, or put in HW queue to do AMPDUs | + | * doing AMSDUs without help from TCP stack: have to have some delays, or put in HW queue to do AMPDUs |
| - | * problem: w/TSO packets can get really large, AMSDUs max out at 4/8k | + | * problem: w/ TSO packets can get really large, AMSDUs max out at 4/8k |
| - | * when packets don't fit in AMSDU, we have to split them and generate new PNs. If we can guarantee TSO limit, then host can still generate sequence numbers | + | * when packets don't fit in AMSDU, we have to split them and generate new PNs. If we can guarantee TSO limit, then mac80211 can still PNs |
| - | * Eric: per-flow limit for TSO/GSO exist, and MSS limits, you need both | + | * Eric: per-flow size limit for TSO/GSO exist, and packet limits, you need both to protect against peers using tiny MSS |
| * can we start small and increase size once we have some traffic with the stations? | * can we start small and increase size once we have some traffic with the stations? | ||
| * terminology: "DSO" - driver segmentation offload | * terminology: "DSO" - driver segmentation offload | ||
| Line 134: | Line 139: | ||
| * hw address from userspace | * hw address from userspace | ||
| * mfr's want to separate mac address from otp area | * mfr's want to separate mac address from otp area | ||
| - | * firmware is 6 bytes long and includes mac address | + | * "firmware" file that is 6 bytes long and has mac address |
| * some people don't want to add device with empty mac and configure it later | * some people don't want to add device with empty mac and configure it later | ||
| * using same interface as firmware loader could be problematic (e.g. would mac address files need to be signed?) | * using same interface as firmware loader could be problematic (e.g. would mac address files need to be signed?) | ||
| Line 147: | Line 152: | ||
| * new attributes in the connect and roaming events | * new attributes in the connect and roaming events | ||
| * can use exisitng nl80211 attributes in vendor commands to avoid copying them? not validated | * can use exisitng nl80211 attributes in vendor commands to avoid copying them? not validated | ||
| + | * problem: vendor extensions could completely change semantics? | ||
| * bt coex subsystem | * bt coex subsystem | ||
| * wireless wants to know BT states, might not have a gpio or register in common, or be on separate chip from BT | * wireless wants to know BT states, might not have a gpio or register in common, or be on separate chip from BT | ||
| Line 160: | Line 166: | ||
| * need to make sure statistics, crypto are still functional | * need to make sure statistics, crypto are still functional | ||
| * Jouni: this can cause fragmentation of features across drivers | * Jouni: this can cause fragmentation of features across drivers | ||
| - | * opw - Luis | + | * opw - Jes |
| * converting orinoco to cfg80211 | * converting orinoco to cfg80211 | ||
| - | |||
| - | |||
en/developers/summits/ottawa-2015.txt · Last modified: 2015/02/27 08:03 by Johannes Berg
Page Tools
