On Fri, Jun 21, 2019 at 3:48 AM Erik Hugne <erik.hu...@gmail.com> wrote: > > Commenting on Jon's response fist. > > Den tors 20 juni 2019 kl 13:26 skrev Xin Long <lucien....@gmail.com>: > > > > On Mon, Jun 17, 2019 at 10:28 PM Jon Maloy <jon.ma...@ericsson.com> wrote: > > > Hi Xin, > > > As I remember the discussion around introduction of UDP media a few years > > > ago, the developer, Erik Huge, only chose to register TIPC as a udp > > > tunnel user instead of regular udp user because it provides a more > > > efficient way to receive packet in kernel space. > > >With UDP tunnel, we could receive packet directly in a callback, while > > >TIPC had to run in a work queue thread in order to read packets from the > > >socket. > The performance was largely dependant on TIPC message size, for large packets > there was no measurable difference, but the tunnel approach was considerably > faster for small packets than the kernel socket interface. > I dont have the numbers, but i think i posted them on this list around 8 > years ago. > > >[...] > > To implement this gso callback, we need to require an ipproto number for > > TIPC, > > and register the callback into inet_offloads by inet_add_offload(). > > And on tx path set: > > skb->encapsulation = 1, > > skb_shinfo(skb)->gso_type|= SKB_GSO_UDP_TUNNEL, > > skb->inner_protocol_type = ENCAP_TYPE_IPPROTO. > > > > Then it will be called by: > > dev_queue_xmit() .. -> skb_mac_gso_segment() ... -> > > udp4_ufo_fragment() -> skb_udp_tunnel_segment() -> > > skb_udp_tunnel_segment() -> tipc_gso_fragment() > > > > btw, do we have an official ipproto number for TIPC already? > > Not afak, but we have an IANA assigned UDP port for TIPC though, 6118. > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=tipc > > TIPC does: > skb_set_inner_protocol(skb, htons(ETH_P_TIPC)); > which will in turn set skb_inner_protocol_type to ENCAP_TYPE_ETHER. > So how about implementing something similar to what's done for > ENCAP_TYPE_IPPROTO, but for ENCAP_TYPE_ETHER? > > In udp_offload.c, something in the line of: > > ... > skb_udp_tunnel_segment(....) > .... > > switch (skb->inner_protocol_type) { > case ENCAP_TYPE_ETHER: > protocol = skb->inner_protocol; > ops = rcu_dereference(ether_offloads[protocol]); > if (!ops || !ops->callbacks->gso_segment) > goto out_unlock; > gso_inner_segment = ops->callbacks.gso_segment; > break; > > .... > And obviously define ether_offloads, and corresponding ether_add_protocol and > ether_add_offload functions. > Maybe no need ether_offloads, dev_add_offload(&tipc_packet_offload) is enough to make the callback be called by skb_mac_gso_segment() from skb_udp_tunnel_segment(), I believe that's also what Jon does now.
It depends on which layer protocol we think TIPC. If we don't have a plan for TIPC working over IP, a transport protocol in the future, packet_offload is fine, otherwise, inet_offloads is also an option. _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
