On Tue, May 29, 2012 at 11:14 AM, Ben Pfaff <b...@nicira.com> wrote: > Thanks so much for applying my comments. Will you please post the > newest version of the MPLS patch? At this time it would be good to > get your > Signed-off-by: Ravi Kerur <rke...@gmail.com> > in the commit log, since it is getting closer. (You can read about > the purpose and meaning of this line in SubmittingPatches.)
<rk> Sure will fix it in my next patch. > > I'd prefer to work on MPLS now, and then on QinQ later, rather than on > both at once. > <rk> ok, no problem, lets finish MPLS and then move on to QinQ. > It's likely that the next step is to get Jesse to take another quick > look at the kernel code. I know that he provided some feedback > before; I hope that you have addressed his comments. <rk> yes, Jesse had mentioned about 1. non-IP + MPLS traffic, I have tested with ARP. 2. TCP Offload + MPLS, I have tested this as well with netperf, iperf + scp. Additional changes are needed here esp. in NIC driver(looked into e1000e driver code from Intel) as it requires handling of new eth_types. For these changes I probably need to work with you and Jesse on how best we can incorporate them. Thanks, Ravi > > Thanks, > > Ben. > > On Tue, May 29, 2012 at 11:08:50AM -0700, ravi kerur wrote: >> Hi Ben, >> >> All your code review comments have been taken care for MPLS. I did >> retest the code after incorporating code review comments. I also >> modified the code for QinQ (common comments which apply to QinQ code >> as well), added additional automation tests in odp.at for QinQ. In >> addition, patch to support MPLS stack bit match is ready as well. >> >> Atleast I feel we can now continue on QinQ (userspace + openflow) >> changes and later on I can work with you and Jesse on kernel code >> review for both MPLS and QinQ. Please let me know how you want to >> proceed. >> >> Thanks, >> Ravi >> >> On Tue, May 29, 2012 at 11:01 AM, <ravi.ke...@telekom.com> wrote: >> > >> > -----Original Message----- >> > From: Ben Pfaff [mailto:b...@nicira.com] >> > Sent: Friday, May 25, 2012 9:32 AM >> > To: Kerur, Ravi >> > Cc: dev@openvswitch.org >> > Subject: Re: [ovs-dev] MPLS and VLAN QinQ patch >> > >> > On Fri, May 25, 2012 at 01:24:00AM +0200, ravi.ke...@telekom.com wrote: >> >> On Thu, May 24, 2012 at 11:58:53PM +0200, ravi.ke...@telekom.com wrote: >> >> > Ben Pfaff writes: >> >> > > get_l3_ttl_and_tos() >> >> > > -------------------- >> >> > > >> >> > > Why does get_l3_ttl_and_tos() consider an unknown IP version as >> >> > > success, with a default? This seems odd. >> >> > >> >> > To handle non-IP traffic i.e push/pop MPLS over non-IP traffic e.g. >> >> > ARP(practical?), VPLS. I had also mentioned in previous discussion >> >> > that MPLS ttl actions will not work for these type of traffic but >> >> > other actions lke push_mpls,pop_mpls, set_mpls_label/set_mpls_tc >> >> > would be. In this function I keep them to default for non-IP traffic. >> >> >> >> But that only comes up in one situation: copying the TTL inward or >> >> outward when there is exactly one MPLS label. In other situations >> >> (pushing an MPLS label or popping one) we know the correct inner >> >> Ethertype either because it's in the packet or because it's an argument >> >> to the action. When we know it, we should use it. >> >> >> >> <rk> Cases for multiple MPLS headers currently happen only at Provider >> >> core routers and yes in that case we don't have to worry, I was thinking >> >> more in terms of Provider-Edge or MPLS termination point. For those >> >> multiple MPLS label case it is already handled and I use existing mpls >> >> header to copy. I will closely look at it one more time probably I am >> >> missing your point. I think you are probably saying extract ethtype from >> >> packet and use it to derive ttl and tos? >> > >> > Yes, that's what I had in mind. >> > >> > Thanks, >> > >> > Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
