Hi, Pranay, First, let's assume that you are talking about IPv4, though you did not mention it explicitly. (The principles in IPv6 are quite similar, though) A packet is sent out in the usual case with the ip_queue_xmit() method. The ip_queue_xmit() method calls the ip_route_output_ports() method in order to perform a lookup in the IPv4 routing tables. see: http://lxr.free-electrons.com/source/net/ipv4/ip_output.c#L352 The results of this IPv4 routing lookup determines on which network device (net_device) the packet will be sent. You should look at the code of ip_route_output_ports() method in net/ipv4/route.c in order to understand the IPv4 routing subsystem and the IPv4 routing lookup. Packets can, under certain circumstances, be sent by the ip_send_skb() method, but this happens when the flow (which consists also of the net_device to be used) is known before. Best Regards, Rami Rosen http://ramirose.wix.com/ramirosen On Sat, May 3, 2014 at 12:43 PM, Pranay Srivastava <pranjas@gmail.com> wrote:
Hi
Referring to Documentation/networking/netdevices.txt
a)
ndo->ndo_start_xmit if written "as is" will be thread safe? [Correct?] NETIF_F_LLTX is not set only then this is true.
But dev_queue_xmit(skb) doesn't seem to take any lock, neither does dev_hard_start_xmit. Please let me know if i'm wrong and where is this lock taken before calling dev_queue_xmit/dev_hard_start_xmit.
b)
Why and when would I want to use rtnl_lock/unlock? Is it like registering multiple device simultaneously?
c)
ndo->ndo_start_xmit is supposed to start the transmission of the skb. However I've a doubt
---> Suppose that there's no room left for the incoming skb in the device buffer, so in that case it would be ideal to call netif_stop_queue. At this the the skb already with the ndo_start_xmit will not be retried again[Correct?]
----> Is ndo_start_xmit required to wait in this case? However if the above spin_lock in a) was taken then this would be a waste. So is it possible that this skb is "deffered" to whenever there's room and return NETDEV_TX_OK? But if we do this we are telling the application that it's packet was delivered so in case there was a timeout set by the application on a reply it would again send us the same packet. So instead of "deferring" is it good to "drop" ?
-- ---P.K.S
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies