Hi Alison and Greg Thanks for the help and best wishes. I will try asking on the kernel netdev mailing list.
On Sat, Jul 1, 2023 at 12:42 AM Alison Schofield <alison.schofi...@intel.com> wrote: > On Wed, Jun 28, 2023 at 04:15:36PM +0530, Abhiram V wrote: > > I am implementing the Parallel Redundancy Protocol (PRP, IEC standard > > 62439-3) as a kernel module for a school project of mine. The code for > the > > module can be found at: https://github.com/ramv33/prp. I have used the > code > > for the HSR module which implements PRP as a reference for my > > implementation since I have zero prior experience with kernel > programming. > > Even though a lot of the design is different, I have used the module as a > > reference for what to do and how to do it. > > Hi Abhiram, > > Sounds like an interesting project. This list may not have the reach > you need. Here are some other places where you may find the specific > help you need. > > There is a netdev mailing list: > https://lore.kernel.org/netdev/ > > If you modeled after, drivers/net/dsa/xrs700x/*, perhaps just send > a message to George McCollister <george.mccollis...@gmail.com> and > CC the netdev mailing list. Folks really like to keep things on the > mailing list - as you've done here. (If I've got the wrong driver, > look in the MAINTAINERS file for the correct one.) > > Another access point is the IRC channel. The netdev folks probably > hang out on #netdev on oftc.net > > Good luck with your presentation! > > Alison > > > > > Let me provide a brief description of what PRP is and what it does. PRP > is > > used to provide hitless redundancy (zero recovery time). It does this by > > having two parallel and independent Ethernet networks. A device is > > connected to both these networks (LAN_A and LAN_B). > > Whenever a frame is sent by the device, it duplicates the frame and > appends > > a trailer (Redundancy Control Trailer - RCT) which contains a sequence > > number, LAN_Id (LAN_A=0xA or LAN_B=0xB) and an LSDU_size (Link Service > Data > > Unit, i.e, Ethernet payload size minus the RCT), and a PRP_Suffix > (0x88FB) > > for a total of 6 octets. > > On reception, the sequence number is used to detect and discard the > > duplicates, removes the RCT, and forwards the frames to the upper layers > > for processing. > > The duplication on transmission, discarding and removal of RCT on > reception > > is done by the kernel module which acts as the Link Redundancy Entity > (LRE) > > as specified in the standard. The LRE is implemented as a virtual network > > interface using a kernel module. The transmission is done by defining the > > ndo_start_xmit function in the netdev_ops structure of my net_device. > > > > The *problem* I have is on reception, specifically with the *removal of > the > > RCT*. The receive handler is registered on device creation using > > netdev_rx_handler_register and netdev_upper_dev_link. > > The receive handler when it detects that the RCT is well-formed (correct > > PRP_Suffix, LSDU_size, LAN_ID for the NIC through which it was received), > > tries to strip the RCT before calling netif_rx() on the skb to forward it > > to the upper layers for processing. > > To strip the RCT, I call *skb_trim* as follows: > > skb_trim(skb, skb->len - PRP_RCTLEN /* 6 */); > > as given in the HSR module. > > > > I have used skb_dump both before and after the call to skb_trim and > > verified that the length is being reduced and that the tailroom is > > increased by 6 bytes. The problem is that when I call skb_trim, the > packet > > is not received by the upper layers. Without calling skb_trim, the packet > > is received correctly but the RCT is consumed by the applications which > > should not be the case. > > > > I used wireshark to inspect the frames at both the sender and the > receiver > > side on the two physical devices and observed the following: > > > > 1. At the receiver side - The IP payload length is different for the > > same frame received through LAN_A and LAN_B. The one received through > LAN_B > > has a payload length 6 greater than that for LAN_A (*6 is the size of > > the RCT*). On checking the ip_rcv_core function, invalid IP payload > > length is one reason that the packet can be dropped. > > 2. At the sender side - The entire packet is the same minus the RCT's > > LAN_ID field for a frame-pair. The IP payload length is correct when I > > capture outgoing frames on the two physical devices. > > > > As mentioned at the top, the code is available at: > > https://github.com/ramv33/prp. Here is a brief overview of the code > > > > 1. The transmission is defined in *prp_tx.c* in *prp_send_skb* which > is > > called by *prp_dev_xmit* function defined in *prp_dev.c* > > 2. The code that sets up the two slave devices to forward frames > > received to the virtual interface is defined in *prp_dev.c* in the > > function *prp_port_setup*. It is called by *prp_add_ports*, which is > > called by *prp_dev_finalize* which is called by the RTNL newlnk > callback, > > 3. The receive handler that is defined in *prp_rx.c, *the function is > > *prp_recv_frame.* It checks if the frame has a valid RCT, duplicates > > discards, and then strips the RCT by calling *strip_rct *before > calling > > *prp_net_if* which removes the Ethernet header and calls *netif_rx* > > > > Hope you can help me find a solution to the removal of the RCT. Point out > > any mistakes that I am making. Thank you in advance :) > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies@kernelnewbies.org > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
